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Abstract 

We present an imperative quantum programming language LanQ which was designed to 
support combination of quantum and classical programming and basic process operations 
- process creation and interprocess communication. The language can thus be used for 
implementing both classical and quantum algorithms and protocols. Its syntax is similar 
to that of C language what makes it easy to learn for existing programmers. In this 
paper, we present operational semantics of the language and a proof of type soundness of 
the noncommunicating part of the language. We provide an example run of a quantum 
random number generator. 
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1 Introduction 

Quantum computing is a young branch of computer science. Its power lies in employing quan- 
tum phenomena in computation. These laws are different to those that rule classical world: 
Quantum systems can be entangled. Quantum evolution is reversible. One can compute 
exponentially many values in one step. 

Quantum phenomena were successfully used for speeding up a solution of computationally 
hard problems like computing discrete logarithm or factorisation of integers [Sho94] . Another 
successful application of quantum phenomena in computing, namely in cryptography, is secure 
quantum key generation [BB84, Eke91, Ben92]. Quantum key generation overcomes the 
classical in the fact that its security relies on the laws of nature, while classical key generation 
techniques rely on computational hardness of solving some problems. A nice example of 
quantum phenomena usage is a teleportation of an unknown quantum state [BBC + 93]. 

For the formal description of quantum algorithms and protocols, several quantum pro- 
gramming languages and process algebras have already been developed. Some of them sup- 
port handling quantum data only, however most of them allow combining of quantum and 
classical computations. Obtaining classical data from quantum systems is done by measure- 
ment which is probabilistic by its nature. This implies that quantum formalisms must be able 
to to handle probabilistic computation. 

Existing formalisms are usually based on existing classical programming languages and 
process algebras. From imperative languages, we should mention Omer's QCL (Quantum 
Computation Language, [OmeOO]) whose syntax is based on that of C language; Betteli, 
Calarco and Serafini's Q language built as an extension of C+- 1- basic classes [BCS01]. How- 
ever, semantics of these imperative languages is not defined formally. Zuliani's qGCL (quan- 
tum Guarded Command Language, [ZulOl]) based on pGCL (probabilistic Guarded Command 
Language) has denotational semantics defined but does not support recursion. 

Many of developed languages are functional because of relatively straightforward definition 
of its operational semantics. Van Tonder developed a quantum A-calculus [vT03]; quantum 
A-calculus was also developed by Selinger and Valiron [SV05]; Selinger proposed functional 
static-typed quantum flow-chart programming language QFC and its text form QPL [Sel04] . 
Another functional programming language QML was developed by Altenkirch and Grattage 
[AG04] and refined into nQML in [LGP06]. 

Quantum process algebras differ to classical ones in the way they handle quantum systems. 
The main issue solved here is that they must guarantee that any quantum system is accessible 
by only one process at one time (because of the no-cloning theorem [WZ82]). The quantum 
process algebras QPAlg by Lalire and Jorrand [LJ04, JL04, Lal05] and CQP by Gay and 
Nagarajan [GN04, GN05, GN06] can describe both classical and quantum interaction and 
evolution of processes. QPAlg was inspired by CCS, originally using nontyped channels for 
interprocess communication. Recently [Lal06], Lalire has added support for fixpoint operator 
and typed channels to QPAlg. 

The presented language LanQ is an imperative quantum programming language. It al- 
lows combination of quantum and classical computations to be expressed. Moreover, it has 
features of quantum process algebras - it supports new process creation and interprocess 
communication. Its syntax is similar to the syntax of C language. In the present paper, we 
define its syntax, operational semantics, and prove type soundness of the noncommunicating 
part of the language. 

The paper is structured as follows: we start with an example of an program written in 
LanQ in Section 2. We then formally define its concrete (Section 3) and internal syntax 
(Section 4). Then basic concepts used later in the paper are defined in Section 6, followed by 
typing system in Section 5.1. In Section 7, we define the operational semantics of the language 
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and prove its type soundness in Section 8. An example of a simple program execution can be 
found in Appendix A. 



2 Informal introduction 



We begin our description of LanQ by an example implementation of a well-known multiparty 
quantum protocol - teleportation [BBC + 93]. Teleportation can be written as the program 
shown in Figure 1. 



void mainQ { 

qbit ipA,^B\ 

tpEPR aliasfor [ipA,i>B]\ 
channel[int] c withends [co,ci]; 

tpEPR = createEPRQ; 
c = new channel[int](); 
fork bert(cQ, ips)', 



} 



angela(ci, if} a)] 



int &erf(channelEnd[int] cj., qbit stto) { 
int i; 

i = recv (ci); 
if (i == 0) { 

opB (stto); 
} else if (i == 1) { 

opBi(stto); 
} else if (i == 2) { 

opB2(stto); 
} else { 

op B 3 (stto); 

} 

do Something Els e(stto); 
return i; 



void ange/a(channelEnd[int] Co, qbit ats) { 
int r; 
qbit <f>; 

4> = doSomethingQ; 

r = measure (BellBasis, <j>, ats); 

send (cq, r); 



Figure 1: Teleportation implemented in LanQ 

We now briefly describe the program. In LanQ, a program is a set of methods. Three 
methods, main, angela and bert, are defined. The control is passed to a method called 
mainQ when the program is run. This method takes no parameters and it returns no value 
what can be seen from the word void in front of the method name. The method angela() has 
to be invoked with two parameters - one end of a channel that can be used to transmit values 
of type int, and one qubit (ie. a quantum bit). It also returns no value. The method bertQ 
takes a channel end and a qubit, and returns a value of type int. 

The method mainQ declares variables ipA,ipB, ^Pepr, c, Co and c\ used in the method body 
in its first three lines: The type of variables ipA, 4>B is qbit. Variable ipEPR is declared to be an 
alias for a two-qubit compound system ipA ®^b- Channel c capable of transmitting integers 
is declared on the next line. The ends of the channel are named en and c\. 

On next lines, the method main invokes method createEPRQ which creates an EPR-pair, 
and stores the returned reference to the created pair into the variable i/jepr- After that, a 
new channel is allocated and assigned to the variable c. This also modifies the channel end 
variables en and c\. The next command makes the running process split into two. One of the 
processes continues its run and invokes the method angelaQ. The second process starts its 
run from the method bertQ. 

The method angelaQ receives one channel end and one qubit as arguments. After declaring 
variables r and </>, it assigns a result of invocation of a method doSomethingQ to <p. Then it 
measures qubits <fi and ats using the Bell basis, assigns the result of the measurement to the 
variable r and sends it over the channel end en. 
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The method bertQ receives one channel end and one qubit as arguments. After declaring a 
variable i, it receives an integer value from the channel end c\ and assigns it to the variable i. 
Depending on the received value, it applies one of the operators opB^, opB\, opB2 and opB^ 
on qubit stto. Then, it invokes a method doSomethingElse() and passes the variable stto as 
an argument to this method. Finally, it returns the value of the variable i to the caller. 

3 Concrete syntax 

In this section, we introduce concrete syntax of LanQ programs. This syntax is used to write 
programs by a programmer. Semantics is defined using internal syntax which is described 
later (see Section 4). 

The syntax is shown in Figure 3. Reserved words of the language are written in bold 
and the identifier names are in capitals. Grammar is given in nondeterministic extended 
Backus-Naur form (EBNF). The root of grammar is the nonterminal program. 

For the sake of clarity, the concrete grammar nonterminals names are long and de- 
scriptive to indicate their meaning. We describe meaning of the most important nonter- 
minals here: program (words derived from this nonterminal represent LanQ programs), code 
(statements), pExpr (promotable expressions, ie. expressions that can act as statements), 
methodCall (method calls), methodParams (method parameters) , assignment (assignments), 
measurement (measurements), expr (expressions), indivExpr (individual expressions, ie. ex- 
pressions not containing any operators), op (operators), method (method declarations), block 
(blocks of code), seq (block-forming statements, ie. statements that can be used in blocks), 
and var Declaration (variable declarations). The other nonterminals are auxiliary and their 
meaning is obvious. 

Definition 3.1. Let m be a method declaration. We call the part of m which was derived 
from nonterminal methodHeader a method header, and the part of m which was derived 
from nonterminal block a method body. 

In the following example, a method named mName is declared. The parts of the method 
declaration are annotated on the right side. 

T mName(Ti a±, . . . ,T n a n ) } method header 

{ 1 

... statements ... > method body 

} J 

Figure 2: Declaration of a method named mName 



4 Internal syntax 

In this section, we define the internal syntax of LanQ. 

Using the concrete syntax, a LanQ program is written as a set of method declarations. 
This notation does not allow direct execution of the program. To define operational semantics, 
we need a representation for the program execution - a syntax that allows us to evaluate a 
program by means of rewriting of program terms. The rewriting rules are presented later in 
Section 7 where the operational semantics is defined. 
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Code 

program 

code 
pExpr 

methodCall 

methodParams 

assignment 

measurement 

expr 

indivExpr 
op 



method+ 

; | pExpr; \ fork \ send \ return \ block \ if \ while 

assignment \ methodCall \ recv \ measurement \ 

new nonDupTypeQ 

methodName ( (methodParams)? ) 

expr (, expr)* 

variableName = expr 

measure ( basisName (, variableName) + ) 
indivExpr (op expr)? 

const | variableName | ( expr ) | pExpr 
+ I - I ® I ••• 



Block structure 

method 

block 
seq 

methodHeader 
methodDeclParamList 
methodDeclParam 
var Declaration 



methodHeader block 
{ (seq)? } 

var Declaration (seq)? \ code (seq)? 
type methodName ( methodDeclParamList? ) 
methodDeclParam(, methodDeclParam) * 
nonVoidType paramName 

nonVoidType variableName(, variableName) * 
channelType variableName withends 

[ variableName , variableName ] ; | 
variableName aliasfor 

[ variableName (, variableName) * ] ; 



Program flow 
fork ::= fork methodCall ; 
return ::= return (expr)? ; 

Conditionals and loops 

if ::= if ( expr ) code (else code)? 
while ::= while ( expr ) code 

Communication 
recv ::= recv ( expr ) 
send ::= send ( expr , expr ) ; 



Types 

type 

nonVoidType 

dupType 

nonDupType 

channelType 

qType 

qBasicType 



void | nonVoidType 
dupType \ nonDupType 
int | bool | ... 

channelEnd [nonVoidType] \ channelType \ qType 
channel [nonVoidType] 
qBasicType((& qType)? 
qbit | qtrit | ... 



Figure 3: Concrete syntax 



The internal syntax is defined in Figure 4. The syntax is similar to the concrete one while 
not containing declarative parts of the concrete syntax and being abbreviated. In the internal 
syntax, we define the following basic syntactic entities: numbers (N), lists (L), recursive lists 
(RL), references (R), constants (C), identifiers (I), types (T), and internal values (v). 
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Promotable expressions (PE) are expressions that can act as statements when postfixed 
by semicolon. Expressions (E) can evaluate to an internal value. The syntactic classes of 
variable declarations (VD) and statements (S) can together create a block. Therefore they 
are together called block-forming elementary statements (Be). A block-forming statement (B) 
is built from zero or more such block-forming elementary statements. 

Remark 4.1. For the sake of clarity, we use the following notation in the rule body. We de- 
note by S an abbreviation of BNF rule body "(S)*", and by E an abbreviation of U (E (, E)*)l". 



N 
L 

RL 
R 

C 
I 
T 
v 

PE 
E 

VD 

S 

Be 
B 



| l\ ... 

i ffi, 

L | [RL] 

none | (Classical, iV) | (Quantum,i?L) | (Channel, N) | 

(ChannelEnd ,AO | (ChannelEndi,iV) | (GQuantum,L) | (GChannel,iV) 
R | true | false | _L | ... 

... | + | — | ... 
void | int | qbit | channel[T] | channelEndfr] \T®T \ ... 

((R,c)) T 

new T() | I = E \ 1(E) | measure(E') | recv(E) 

1 | v | (E) | PE 

T I; | channel[T] / withends [1,1]; \ I aliasfor [I]; 
; | PE; | {B} \ if (E) S else S \ while (E) S | 



return; 

VD | S 
B~e 



return E; \ fork 1(E); \ send(£',£'); 



Figure 4: Internal syntax 



Configuration syntax specifies formal notation of process configuration which is described 
in Subsection 7.3. 

If a statement or an expression contains a subexpression, this subexpression is evaluated 
separately and the evaluation result is substituted in place of the subexpression. For this rea- 
son, we introduce a concept of a hole (•) which stands for the awaited result of subexpression 
evaluation. We call a term not containing a hole a closed term. 

The terms containing a hole are defined by nonterminals Sc and Ec which represent 
partially evaluated statements and expressions, respectively, whose subexpression is being 
evaluated. In other words, they represent evaluation contexts. We also define syntactic 
entities for runtime errors (RTErr) and term stack elements (StkEl). 

Before a method can be invoked to be run, we must transform its body to the internal 
representation. Fortunately, the method bodies derived using concrete syntax and internal 
syntax rules differ only in the following: 

• In internal representation, all if statements have else part, ie. a statement if (E) P is 
rewritten to if (E) P else ;, 

• In internal representation, all constants C are represented by internal values ((none, C))j 
where T is the type of the constant C, 

• In internal representation, all operators are written in the prefix notation and seen as 
method calls, ie. E F is converted to Q(E,F). 
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Ec ::= I = • | /(v, • ,E) | measure(v, • ,E) | recv( • ) 

Sc ::= •; | if ( • ) S else S | fork /(v, • ,E); | send( • ,E); | return • ; 

RTErr ::= UV | OQV | ISQV 

StkEl ::= B \ E \ Ec \ Sc \ RTErr | o L | o M 

LMS ::= local memory state as described in Subsection 7.3 

VP ::= variable properties as described in Subsection 7.3 



LS ::= {LMS, VP, StkEl) 

P ::= LS | LS \\ P 

GS ::= ((DM,L),[I\=\I]) where DM is a density matrix 

Sys ::= [GS\P] 

Univ ::= p» Sys \ p» SysSUniv 



Figure 5: Configuration syntax 



There is obviously an algorithm which rewrites any method body derived using the con- 
crete syntax to the internal representation. 

An example of a block written using the concrete syntax and its internal representation 
is shown in Figure 6. 



{ 



int r; 
qbit <fi; 

(j) = doSomethingO; 

r = measure (BellBasis, (j), ats); 

send (c , r); 

if ( r == 0) { 

measure (StdBasis, 4>); 

} 

(a) 



{ 



int r; 
qbit 4>; 

4> = doSomethingO] 

r = measure (BellBasis, (j), ats); 

send (c , r); 

if(==(r,0)){ 

measure (StdBasis, (j)); 
} else ; 

(b) 



Figure 6: Block derived using concrete syntax (a) and the same block converted to internal 
syntax (b). 



5 Typing 

5.1 Typing rules 

LanQ is a typed language. This feature enables us to detect errors arising from incorrect 
usage of methods, variables and constants at compile time. 
First, we define the ground types used in LanQ: 

• void - a type with only one value: J., 1 

1 This type is a unit type. In several other languages, it is called differently, eg. unit in OCaml or () in 
Haskell. We have decided to use the name void as usual in C-based languages because LanQ follows C language 
also in many other aspects. 
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5 TYPING 



• int - a type of integers, 

• bool - a type of truth values true and false, 

• qciit - a type of references to d-dimensional quantum systems. Types which are often 
used are given special names: instead of writing q2it, one can write qbit, and in place 
of q3it one can use qtrit. 

• Ref - a type of references, defined later in Section 7.1, 

• RTErr - a type of runtime errors, and 

• MeasurementBasis - a type of measurement bases. 

The ground type system can be indeed extended when needed. 

If T is a type, then channel[T] is a type of references to a channel capable of transmit- 
ting values of type T, and channelEnd[T] is a type of references to ends of such a channel. 
Further, let Si, S n , S be types for n > 0. Then a method type T is defined to be the type 
Si, S2, S n — ► S. We call types Si, . . . , S n argument types and the type S a return type. 

Definition 5.1. We define a set Types of types of classical values. We denote by val(T) a 
set of values of type T and define a set Values as a set of values of all types: 



After parsing a program, the method declarations are stored in a triplet (Mt, Mjj, Mb) 
of partial functions. We call this triplet a method typing context where: 

• Mf(m) which returns the method type for a method m (the method type is straight- 
forwardly determined from the method header), 

• M#(m) returns the method header for a method m, and 

• Mfl(m) which returns the method body represented using internal syntax for a method 



We provide typechecking rules in Figures 7, 8, 9 and 10. These rules use a typing context 
which is a pair (M; T) consisting of: 

• M is a method typing context, 

• r is a variable typing context - a partial mapping T : Names Types that assigns a 
type to a variable name. We write a variable typing context r as T = a± : Ti, . . . , a n : T n 
meaning that the type Tj is assigned to the variable dj. 

The extension of a context T by a variable b of type T& is written as T,b : T&. It is 
undefined if T(b) is defined and T(b) 7^ T&. Otherwise it is defined as: 



Let P be a program whose internal representation is stored in a method typing context 
(Mt, Mh, Mb). We call this program well-typed if the premise of the rule T-Program is 
satisfied for this method typing context. This check is passed iff all the declared methods 
satisfy the typing rule T-Method. 




val(T). 



TdTypes 



rn. 




T(x) otherwise. 



if x = b 
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5 TYPING 



Vm G dom(M T ) : (M T , M H , M B ) h T M H (m) : M T (m) 

J- "Program ■ — . - - — — — — — — — : 

h (M T ,M H ,M B ) 



T-Method 



T = void V RetOk{M B (m)), 

(M T , M H , M B ); ^ :T u ...,a n : T n , ©retVal : T h T M B (m) : void 
(M r , M H , M B ) h T T m(Ti a\, . . . ,T n a n ) : Ti, . . . ,T n —> T 

Figure 7: Typing rules for program and method declaration 



T-VarDecl M ^j: T ^-r Jn:T r h lV 

M;Fh T T I ,...,I n ;B :T 

m , r „ M;T,I : channelfT], ii : channelEndpl J 2 : channelEnd[Tl h T B : T 

T-VarDeclChE — ' — — — z—. — = z — 

M; T \~t channel[T] I withends [h,h];B : T 

Vi € {1, . . . , ra} : M; F hy ij : T\ where T\ is a quantum type, 

M;F,I ■ ®!Li Ti h T B:J 

T-VarDeclAlF ' ' ^ y '~ 1 = = 

M; F h T I aliasfor [I u . . . ,I n ];B : T 

Figure 8: Typing rules for variable declarations 



T-Skip 

T-PromoExpr 

T-Block 

T-BlockHead 

T-If 

T-While 
T-ReturnVoid 

T-ReturnExpr 

T-FORK 

T-Send 



M;F H T ; : void 

M; r \~t PE : T 
M; F \~t PE; : void 

M; F h T B : void 
M;Th T {5} : void 

M ; T h T 5e : void M ; T h T Sei . . . Be n : void 

M; F h T 5e Be x ... 5e„ : void 

where -Beo 7^ V^Z) 

M; T h T E: bool M; r h T S Q : void M ; rh T 5i: void 
M; r h T if (E) So else 5i : void 

M; Fh T E: bool M;F h T S : void 
M; r h T while (E) S : void 

M; T, ©reiFaZ : void hy return; : void 

M ; r,@reiya/ : T h T E : T 
M; F h T return E; : void 

M; r \~t 1(E) : T / is a classical method 
M;Th T fork !(£); : void 
M; Fh T E : channelEnd[T] M; T h T £1 : T 
M; T \~t send(£'o, Ei); : void 



Figure 9: Typing rules for statements 
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T-Var 
T- Value 

T-Bracket 
T-Alloc 

T-ASSIGN 

T-MethodCall 



M;T,I : T h r I : T 

M;Th T ((R,C)) T :T 

M;T h T E : T 
M;Th T (£7) : T 

T is either a quantum type (Qd) or a channel type (channel[T]) 
M;Th T new T() : T 

M ; r,/:Th T £:T 



Af T (/) = S ,...,S r 



M;T bp I = £ : T 
T M;Th T E :S 



M; T \~t E n : S n 



M;Th T I(E , . . . ,E n ) : T 

where M 



(M T ,M H ,M B ) 



T-Measurement 



T-Recv 



M;T £"o : MeasurementBasis, 
\/i G {1, . . . , n} : M; T \~t E{ : Tj where Ti is a quantum type 
M; T \~t measure (E'oj-E'i, • • • iE n ) : int 
M;T h T E : channelEnd[T] 
M;Th T recv(E) : T 



Figure 10: Typing rules for expressions 



Typechecking of a method in the rule T-Method is a little more complicated. The reason 
is that we require any method m whose return type is not void to return a value of appropriate 
type in all possible control paths which the evaluation of this method can take. The return 
type is for the sake of typechecking stored in the formal variable ©retVal. 

This can be checked at compile time. We split this requirement into two: 

(1) during evaluation, the method m body always reaches a return statement (or invokes 
a runtime error or diverges), and 

(2) any value returned by a return statement during evaluation of the method m body is of 
appropriate type. This is checked by typing rules T-ReturnVoid and T-ReturnExpr 
in cooperation with T-Method. 

For formal definition of the condition (1), we define a predicate RetOk. 

Definition 5.2. Let B be a block-forming statement. We define a predicate RetOk as: 



RetOk{B) 



true if B 

RetOk(S t ) A RetOk(S e ) if B 

V Be .RetOk(B ei ) if B 

RetOk(B') if B 

false otherwise 



return E; 
if (E) S t else S e 
Beo Be\ . . . Be n 
{B>} 



This predicate does not handle the case B = while (E) S because evaluation of the 
condition E is undecidable at compile-time. Hence even for the straightforwardly always- 
terminating case B = while (true) return 1;, RetOk(B) is not satisfied. Therefore the 
predicate is only approximate. 
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Later we prove a lemma stating that if the predicate RetOk is satisfied on B then any 
control path of evaluation of B reaches a return; or return E; statement, or a runtime error, 
or diverges (see Lemma 8.15). Thus, if B is a method m body and RetOk(B) is satisfied, 
the evaluation of method can either reach some return statement, lead to a runtime error, 
or diverge. 

Definition 5.3. We call a method m well-typed if the premises of rule T-Method are 

satisfied for this method. 

Remark 5.4. Note that if a method m is well-typed and its return type is not void then its 
body contains only return E; statements, ie. no return; statements. 

The rest of the typing rules is usual: The rules for typechecking variable declarations in 
Figure 8 check the block-forming statement can be typechecked with the variable context 
extended with the newly declared variables. 

We formally regard all statements to be of type void what is seen in the typechecking rules 
in Figure 9. These rules are quite usual up to the rule T-Fork. This rule requires that the 
method, which should be a new process run from, is classical. This is natural requirement 
as running a new process, which is by its nature a classical object from a quantum operator, 
would be a nonsense. 

The typechecking rules for expressions shown in Figure 10 are designed as usual. 

6 Basic concepts 

Before we continue with formal definition of the semantics, we must define several useful 
functions and structures. First we define notation used in the rest of the article. 

6.1 Notation 

Notation 6.1. Let S be a set, _L ^ S. Then S± = S U {J-}. We denote a set of natural 
numbers with zero N U {0} by No- 

Definition 6.2. Let S be a set. An S'-list s = [si,...,s n ] is a list where n G No and 
si,..., s n E S. Set of all finite S-lists {s \ s is a finite S-list} is denoted by Sn. 

Definition 6.3. Let m,n E No- Let L = . . . ,l n ], K = [ki, . . . ,k m ] be lists. Then \L\ 
is a length of a list L, \L\ = n. Concatenation of lists L and K is defined as L ■ K = 
[li, . . . , l n , ki, . . . , k m ]. Set of list L elements is defined as set(L) = {l\, . . . , l n }. 

6.2 Reference-related concepts 

We use the following specially formed lists for storing references to quantum systems. 
Definition 6.4. Let S be a set. We define a recursive S'-list recursively as: 

• Any S-list [s±, . . . , Sk] is a recursive S-list, 

• A list [ei, . . . , e m ] is a recursive S-list for any m G No if e\, . . . , e m are recursive S-lists. 
For example, [[[1, 2, 3], [2, 3]], [1]] and [] are recursive N-lists. 

Recursive S-lists are used for the representation of quantum system references in the 
following way: 

A reference to a quantum system, be it compound or not, is specified by a recursive N- 
list. Quantum systems are stored in indexed registers in the quantum memory, one quantum 
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system per one register. The (unique) index is assigned to a quantum system when it is 
allocated. The reference to the system with index n is a recursive N-list [n\. 

Let us have two quantum systems <p and rb whose indices are 1 and 2, respectively. The 
references to these quantum systems are = [1] and tv, = [2], respectively. A reference to a 
compound system p consisting of the two quantum systems 4> and ip is then a recursive N-list 
r p = [ r <j>i r ip] = [[1]j[2]]. Note that the structure of p, ie. that it consists of two systems, 
corresponds to the structure of the reference r p - it is built up from two elements. 

Notation 6.5. The set of all finite recursive S-lists {s \ s is a finite recursive S-list} is de- 
noted by iSjq] . 

Recursive S-lists allow us to nicely capture quantum system structure in the reference. 
However, when working with referred quantum systems, eg. applying some unitary operator, 
we do not want to bother with the structure - we only need a list of indices of the affected 
quantum systems. To get such a linearized list out of the structured one, we define the 
following function: 

Definition 6.6. For a recursive S-list s £ <%)], we define a function linearize : S^ — > Sp 
which converts a recursive S-list into an S-list: 



linearize(s) = s if s G Sp 
linearize ([ei, . . . , e m ]) = linearize(ei) • . . . • linearize (e m ) where ei, . . . , e m G S^ 



If a reference R contains a special element _L which denotes a reference to nonexistent 
quantum system, we consider the reference R itself to refer to nonexistent quantum system. 
Hence linearization of such a reference returns _L: 

Definition 6.7. For a set S±, we define a function linearizej_ : (Sjjjo] — ► i^±)[] U {-L} as; 



linearizej_(s) = 



J linearize(s) = [s±, . . . , s n ] if Si ^ _L for all 1 < % < n 
1 _L otherwise 



Definition 6.8. Let S be a set. We define a function set^j : S^ — > S for getting the set of 
recursive list items regardless of the structure as set[Q](Z) = set(linearize(/)). We also define 
function | — | [o] : ^fo] ~^ ^ f or 9 e ^ n 9 length of a recursive list regardless of the structure as 
\l\[(j\ = | linearize (7) | . 

6.3 Variable-related concepts 

We use partial functions to capture variable properties, eg. mapping a variable name to a 
place in memory where the variable value is stored, or a mapping to the variable type. We 
define several useful functions for handling these partial functions describing variables. 

Adding a new variable to a set of known variables is represented by extending the domain 
of the appropriate partial function with the new variable name. We call this function an 
update. Sometimes we only want to update a variable property if the updated variable is 
already contained in the domain of the updated function, eg. change a memory reference 
referred by the variable. We call such an operation an replacement. In general, we define 
these functions in the following way: 
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Definition 6.9. Let f : X — 1 Y be a partial function. For x G X,y G Y , we define 
replacement /[x h- ► y] : X — v Y croc? update /[a; i— ► y] + : X — 1 Y as: 



/[x i ^ y](z) 

and 



y if x = z and f(x) is defined, 
f(z) otherwise, 



f[x i ^ y]+(z) 



y if x = z, 
f(z) otherwise. 



Note that the f[x i— ► y](x) is defined iff /(x) is defined while /[x i— > y] + (x) is defined even 
if f(x) is not defined. 2 

We need to store different variable properties: variable type, names of channel ends cor- 
responding to given channel etc. Each property is represented by a separate partial mapping. 
Hence variable properties are described by a tuple of such partial functions. 

Definition 6.10. A partial function tuple is a tuple f = (fo, . . . , f n ) where fo, ■ ■ ■ , f n o,re 
partial functions. 

We will need to capture variable scope during a method evaluation. For this reason, we 
define concepts of list of partial function tuples and list of lists of partial function tuples. Their 
usage is in more detail explained in Subsection 7.2. We also extend update and replacement 
functions to lists of partial function tuples and lists of lists of partial function tuples. 

Definition 6.11. We define list of partial function tuples recursively as: 

• O is an ( empty ) list of partial function tuples, 

• [K o L f] is a list of partial function tuples if K is a list of partial function tuples and f 
is a partial function tuple. The symbol o L serves as an element separator only. 3 

Definition 6.12. For a list of partial function tuples K, we define a replacement K[x >— ► y]i 
and an update K[x t— > y]+i of outermost x in an i-th partial function of a list of partial 
function tuples K as: 



[K °l {fo, ■ ■ -,fn)}[x H-> y]i 
D[x h-> y]i 

[K o L (f , . . . ,f n )][x ^ y] +:i = [Ko L (f ,...,fi[x >-> y] + ,...,f n )} 



Definition 6.13. We define a list of lists of partial function tuples recursively as: 

• ■ is an (empty) list of lists of partial function tuples, 

• [L\ o G K] is a list of lists of partial function tuples if L\ is a list of lists of partial 
function tuples and K is a list of partial function tuples. The symbol o G serves as an 
element separator only. 4 

2 The + sign in function index means "add the mapping from x to y even if it was not defined yet". 
3 L in o L stands for local. 
4 G in o G stands for global. 



| [K o L (f , . . . , fi[ x ^ y], . . . , /„)] if fi(x) is defined 
[ [K[x i ^ y]i o L (f , f n )} otherwise 

□ 
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Definition 6.14. For a list of lists of partial function tuples L, a replacement L[x t— > y]i 
and an update L[x i— > y]+ t i of mapping of x in the outermost list of partial function tuples is 
defined as: 



[Li o G K][x i ^ y]j 
■ [x i ^ y]» 


def 
def 


[Li oq K[x \- 
■ 




[Li o G K)[x i-> y) +ti 
M[xh^> y] +)i 


def 
def 


[Li o G if [a; t— 
■ 





Last, we define a coalesce 5 function * of two partial functions f,g:A—^B. Coalesce g* f 
is a partial function which for (g* f){x) results into f{x) if f{x) is defined, otherwise to g(x): 

Definition 6.15. Let f,g : A ^ B be partial functions. We define a coalesce of g and / 
g * f : A ^ B as: 

f(x) if f(x) is defined 
g(x) otherwise. 

Definition 6.16. We define Names to be a set of all identifier names. 



(g*f)(x) 



7 Operational semantics 

In this section, we define the operational semantics of the LanQ programming language. 



7.1 Memory model 

In this subsection, we describe the memory model used in LanQ implementation. 

Our model abstract machine uses a memory to store values. As we work both with dupli- 
cable and nonduplicable data, we have two types of memory: system and local. All processes 
manage their own memory - a local process memory where duplicable values are stored. Sys- 
tem manages the system memory where nonduplicable resources are stored. Processes cannot 
access the system memory directly, they work with resources by means of references to the 
system memory. This is transparent to the programmer. Memory model is depicted in Figure 
11. 

This memory model allows us to assign a reference to the same nonduplicable resource to 
many different variables. It also allows simple definition of communication of resources - the 
global reference to system memory is unmapped from the sending process and moved to the 
receiver. 

It is however also a possible source of runtime errors. Consider a situation when a process 
sends away a qubit. Then the mapping from its local process memory to the place system 
memory where the qubit physically exists is removed but the mapping from variables to the 
local process memory is preserved. If a process then tries to use the value of such a variable, 
a runtime error signalling uninitialized variable usage occurs. 6 

A memory reference specifies a position of a value in the memory. We distinguish two 
basic types of references: 

5 The name coalesce is given because this function is similar to the COALESCE function defined in SQL-92 
standard. 

6 Note that the same behaviour would be exhibited if we unmapped the references directly from variables 
to local memory - in that case we would have to deinitialize all the variables referring to the resource (this 
operation would however cost more time than the previously described one) and the issue with uninitialized 
variables remains. 
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GQuant um, [lj ) (GChannel,0 




Figure 11: Memory model of LanQ. Several processes are currently running, their memories 
are shown as red boxes. Variable names are shown in a circle, duplicable variables are shown in 
green, nonduplicable ones in red. The variables v (integer), p (quantum system), ip (quantum 
system) and c (channel) belonging to one process refer to places in its local memory shown as 
yellow containers. The containers refer to values - a value 3 in the case of variable v container 
and references to the system memory in the rest of the cases. 



• Local references specify places in a local process memory where variable values are 
stored. All variables used during evaluation are assigned local references. A special 
local reference none refers to no value. We have four kinds of local references: 

— References to local classical value memory: Refci = {none} U ({Classical} x Nj_), 

— References to local quantum systems reference memory: 
RefQ = {none} U ({Quantum} x (Nj_)[oj), 

— References to local channel reference memory: Refch = {none}U ({Channel} xN), 

— References to local channel end reference memory: 
RefchE = {none} U ({Channel End^, ChannelEnd\} x N). 

The set of local references is defined as: 

Ref L = Refci U Ref Q U Ref Ch U Ref ChE - 

• Global references refer to resources stored in system memory. 

— References to system channel memory: Refcch = {-L} U ({G Channel} x Nj_), 

— References to system quantum memory: RefcQ = {-L} U ({GQuantum} x Nn). 

The set of global references is defined as: 

Ref G = Refcch U Ref GQ . 

A set of all references is defined as: 

Ref = Ref G URef L , 
and a set of references to nonduplicable values is denoted by: 

Refnd = RefQ U Refch U Ref C hE- 

Definition 7.1. A memory reference is an element from the set Ref. We define Ref to be 
the type of memory references. 

Remark 7.2. Note that a memory reference is a classical value, therefore Ref G Types. 
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7.2 Variable properties storage 

In this subsection, we informally introduce structure used for handling variable properties. 

Variable properties is a structure where properties of variables neccessary for correct 
handling the variables are stored while respecting their scope: The actually running method 
has access only to variables declared in this method, it cannot access any variable from the 
caller method. Moreover, the validity of a variable is limited to the block in which the variable 
is declared. 

The properties of a variable are formally described later in Subsection 7.3. They are 
represented by partial functions which, given a variable name, return: 

• A reference to local process memory where the value of the variable is stored, 

• Variable names representing individual ends of the channel (if the given variable repre- 
sents a channel), 

• List of variable names representing quantum systems which are subsystems of the com- 
pound quantum system (if the given variable represents a compound quantum system), 

• A type of the given variable. 

Therefore we have a quadruple of partial functions that represent variable properties: 
/ = {fvari fch-> fqa, ftype)- Indeed, this quadruple is not enough for handling variable scope. 

Respecting a variable scope is achieved by using lists of partial function tuples and lists 
of such lists: 

• A variable can be accessed only from within the block where it was declared. This is 
ensured by using a list of partial function tuples (separated by o^), where a new tuple 
is appended to the list when a block is started and removed when the block ends, 

• Only variables from the currently running method are accessible to this method. This 
is ensured by using a list of lists of partial function tuples (separated by oq) where a 
new list of partial function tuples is appended when a method is invoked, and removed 
when a method finishes. 

We show the manipulation with a variable properties structure on an example. Consider 
the following method a: 

int a(int c) 

1 { 

2 bool b; 

3 b = true; 

4 if (b) { ' 

5 int i; 

6 } 

7 return 3 + c; 

8 } 

We show the variable properties construction as the individual lines of the method are 
executed. As the formal notation of the variable properties is not well-readable, we also 
provide the reader with its graphical representation. The representation uses the following 
notation: 
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A variable properties tuple (/ won f ch , f qa , f type ) is represented as: 



^ fvar 
fch 



fqa 
\ftypej 



A list of variable properties [K f] is represented as: 



/ 
K 



A list of lists of variable properties [L\ oq K] is represented as: 



We assume that the original variable properties were vpc right before calling the method 
a. When the method a is called, a list of variable properties [□ o L ([c m r c ] ,[],[], [c 
int, ©retVal i— ► int] )] is appended to vpc- 

[vpc °G [□ °L ([cm r c ], 0,[], [c m int, @re^aZ m int])]] 

(see Figure 12(a)). In this appended list, method parameters values are passed to the called 
method; in our case, the method parameter c refers to the memory as set by the reference r c . 

On line 1, a new block is started, therefore a new empty variable properties tuple is 
appended: 

[vp G o G [[□ o L ([c mt c ], [],[], [cm int, ©retVal Mint])] o L 0]] 

(see Figure 12(b)). On the next line, a variable b is declared, hence the head element of the 
inner list is modified: 

[vp G °g [[□ °L ([c m r c ], [], [], [c m int, ©retFo/ m int])] o L ([6 none], [],[], [b m bool])]] 

(see Figure 12(c)). On line 3, b is assigned a value true which is stored in the memory in 
a place referred by a reference r\,. This modifies f var element of the appropriate variable 
properties tuple: 

[vp G o G [[□ o L ([c m Tc ], [}, [}, [c m int, ©retFaZ m int])] o L ([b ^ r b ], [], [], [6 m bool])]] 

(see Figure 12(d)). On line 4, a new block is started, therefore again a new empty variable 
properties tuple is appended: 

[vp G o G [[[□ o L ([ c m r c ], [], [], [c m int, ©reiVa/ m int])] o L ([6 ^ r 6 ], Q, [], [b m bool])] o L 0]] 

(see Figure 12(e)). On line 5, a new integer variable i is declared what is reflected in the inner 
list head variable properties tuple: 

[vp G o G [[[□ o L ([ c m r c ), [], [], [c m int, ©retVal m int])] o L ([6 m r 6 ], [],[], [b m bool])] o £ 

(h none],[],[],[iM int])]] 

(see Figure 12(f)). On line 6, the block ends, hence the appropriate variable properties tuple 
is discarded: 

[vp G o G [[□ o L ([ c m Tc ], [], [], [c m int, ©retVal m int])] o L ([6 h+ r fe ], [], [], [6 m bool])]] 

(see Figure 12(g)). Finally on line 7, the method execution ends, hence all local variable 
properties tuples are discarded and the original variable properties structure is restored: 

vp G 

(see Figure 12(h)). 
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\ 



\c i — > int, ©retVal h-> int/ 

□ 

VPG 



(a) Before execution of line 1 



b i — > bool/ 



\ 



yc h-» int, ©retVal h-> int/ 
□ 

"Pg 



(d) After execution of line 3 



b i — > bool/ 



\ 



yc i — > int, QretVal h-> int/ 

□ 



«Pg 




(b) After execution of line 1 



b^n \ 



fo M bool/ 



\ 



c i — > int, QretFa/ i-» int/ 
□ 



«Pg 



(e) After execution of line 4 



<'Pc; 



ib h-> none\ 
\fe i — ' bool / 



\ 



c i-t int, QretyaZ i-> int/ 
□ 

i'Pg 



(c) After execution of line 2 



none\ 



i i — > int / 



6 « r 6 \ 



b i — > bool/ 



\ 



c h-» int, QreiFaZ i-> int/ 
□ 

t'PG 



(f) After execution of line 5 



(g) After execution of line 6 (h) After execution of line 7 

Figure 12: Variable properties stack construction when invoking the method a 
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7.3 Configuration 

In this subsection, we formally define abstract machine configuration which is later used for 
the definition of LanQ operational semantics. 

A configuration of the abstract machine used for the definition of LanQ operational se- 
mantics is composed of two basic parts - global and local. The global part of the configuration 
stores information about resources - a quantum state of the whole system and a relation be- 
tween channels and their ends. The local part of the configuration stores information about 
individual processes - the state of their local memory, variables, and terms to be evaluated. 

A configuration C describing n processes running in parallel is written as: 

C = [gs | Isi || • • • || ls n ] 

where gs is the global part of the configuration and Isj represents the local process configu- 
ration of j-th process. 

The components of the abstract machine configuration are formally defined as follows: 

• Global part of the configuration: a pair (Q, C) where: 

— Q describes the state of quantum particles and their dimensions. 

In the present paper, we represent the quantum state of the system by a pair 
(p, L) of a finite density matrix p and a finite list L of natural numbers. The list 
L represents dimensions of individual quantum subsystems. The order of the list 
elements is given by order of quantum system allocations. 

— C represents the channel part of the configuration. 

Channels and their ends are stored as pairs (cq,ci) written as cq| \c\ where Co 
and c\ represent individual ends of one channel. 

• Local part of the configuration: it defines state of one process, hence we call it a local 
process configuration. It is a triplet (Ims, vp, ts) where: 

— Local memory state Ims is a quadruple of partial functions, Ims = 
(lmsci,lmsQ,lmsch,l ms ChE) which stores the state of classical memory and ref- 
erences to non-duplicable resources available to the process: 

* Imsci : Refci ~^ Values is a partial function which returns a (classical) value 
stored at the given position in memory. The set of all such partial functions 
is denoted by LMSci, 

* ImsQ : RefQ — RefcQ returns a global reference to quantum systems given 
by the local quantum reference. The set of all such partial functions is denoted 
by LMSq, 

* Imsch '■ Refch — 1 RefGCh returns a global reference to the channel given by 
the local channel reference. The set of all such partial functions is denoted by 
LMSch, 

* ImschE '■ RefchE Rs-fcch returns a global reference to the channel corre- 
sponding to the given local channel end reference. The set of all such partial 
functions is denoted by LMSche- 

To simplify the notation, we regard Ims itself as a partial function. Note 
that RefcQ Q Values and Refcch Q Values. Now we can define Ims = 
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(lmsci,lmsQ,lmsch,lmschE) '■ RefL — 1 Values as: 



lms{r) 



lms C i{r) ilr&Refci, 

lms Q (r) HreRefQ, 

lms C h{r) iireRefch, 

lms C hE(r) if r G RefchE, 

_L if r = none. 



The set of all such quadruples Ims is denoted by LMS. 

— Variable properties vp represent various properties of variables while respecting 
variable scope. They are stored as a list of lists of partial function tuples / = 

{fvan fchi fqai ftype) where: 

* fvar '■ Names — Refi maps a variable name to a local reference, 

* fch '■ Names — Names x Names maps a channel variable name to variable 
names representing ends of the channel, 

* fqa '■ Names — Names ^ maps a variable name representing a quantum system 
to variable names that represent its subsystems, 

* ftype '■ Names — 1 Types maps a variable name to the variable type. 
We call the quadruple / a variable properties tuple. 

We define VarPropi to be a set of all finite lists of such partial function tuples 
/. These lists are built to reflect the block structure of a method as described in 
Subsection 7.2. 

We define VarProp to be a set of all finite lists of lists of such partial function 
tuples /. These lists are built to reflect the method calls as described in Subsection 
7.2. 

We define an empty variable properties tuple as a partial function tuple 0: 

= {fvar j fchi fqai ftype) 

where dom(f var ) = dom(f ch ) = dom(/ ga ) = dom(/ i j /pe ) = 0. 

— Term stack ts: stack of terms to be evaluated. For the sake of readability, we use 
a notation where individual stack items are underlined. An empty term stack is 
denoted by e. 

A configuration can evolve to a probabilistic mixture of configurations, so called mixed 
configuration. A mixed configuration is written as: 

q 

^i=iPi • [g s i I ^ s i,i II ' ' ' II ls i,n] where ^Pi = 1. 

i 

It represents configurations of q different computational branches, each of them running with 
probability pi. A configuration is a special case of a mixed configuration where q = 1 and 
Pi = 1. 



7.4 Variable properties handling functions 

In this subsection, we define functions for variable properties handling. 

First we define functions for retrieving information about variables using variable prop- 
erties. The defined functions are designed so that they only work with variables accessible 
from the actually running method. We achieve this by inspecting the structure of the variable 
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properties. If the variable properties given as one of the function arguments are represented 
by a list of lists of partial function tuples L = [L\ oq K] then we consider only its second 
element - the list of partial function tuples K. We do not consider the variable properties 
from L\ as they are inaccessible to the current method (as explained in Subsection 7.2). 

We then walk through the obtained list of partial function tuples [K f]. We attempt 
to get the requested information about requested variable using appropriate partial function 
from the variable properties tuple. If the requested information about the variable cannot 
be obtained from the actual tuple, we repeat this procedure with the list of partial function 
tuples K. This procedure is designed so that it respects block scope of variables (as in more 
detail explained in Subsection 7.2). 

Definition 7.3. We define a partial function varRef : Names x VarProp —* Refi, for 
getting a local reference from a variable name and variable properties as: 

varRef (x, [L% o G K]) = varRef l{x, K) 

where varRef l : NamesxVarPropi Refi is a partial function for getting a local reference 
from a variable name and a list of partial function tuples: 



varRef L (x, [K o L (f var , f ch , f qa , f ty p e )}) 



fvar(x) if fvar (x) is defined 

varRef l(x,K) otherwise 



Definition 7.4. We define a partial function chanEnds : Names x VarProp — Names x 
Names for getting variable names that represent individual ends of given channel from a 
name of the channel and variable properties: 

chanEnds(x,[L\ o G K]) = chanEnds l(x, K) 

where chanEnds l '■ Names x VarProp^ — 1 Names x Names is a partial function for getting 
variable names that represent individual ends of given channel from a name of the channel 
and a list of partial function tuples: 



chanEnds L (x, [K o L (f var , f ch , f qa , f type )]) 



\fch{x) if fch{x) is defined 

\ chanEnds l(x, K) otherwise 



Definition 7.5. We define a partial function aliasSubsyst : Names x VarProp Names^ 
for getting a list of variable names that represent individual parts of a compound system from 
a name of the compound system and variable properties: 

aliasSubsyst(x,[Li o G K]) = aliasSubsysti(x, K) 

where aliasSubsysti : Names x VarPropi — x Names^ is a partial function for getting a list 
of variable names that represent individual parts of a compound system from a name of the 
compound system and a list of partial function tuples: 



aliasSubsyst L (x, [K o L (f var , f ch , f qa , / fype )]) 



fqa(x) if f qa {x) is defined 

alias S ubsy st l(x, K) otherwise 



Definition 7.6. We define a partial function typeOf : Names x VarProp — 1 Types for 
getting a variable type from a name of a variable and variable properties: 

typeOf(x, [Li o G K)) = typeOf L (x, K) 

where typeOf^ : Names x VarPropi — 1 Types is a partial function for getting a type from 
a name of the variable and a list of partial function tuples: 



typeOf L (x, [K o L (/„, f ch , f ga , ftype)]) 



\ ftype(x) if ftype(x) is defined 

\typeOfi{x,K) otherwise 
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7.5 Local memory handling functions 

Next we define functions for local memory state handling. 

LanQ allows the programmer to create multiple processes. These processes can commu- 
nicate with each other, namely a process can send some resource, ie. a quantum system or 
a channel, to another process. In that case, the language must assure that the sent resource 
becomes unavailable to the sending process. 

For this reason we define a function unmap n( i 7 which invalidates a reference to resource 
in given local memory state. By invalidation we mean setting the appropriate local reference 
to the sent resource to point to _L in the local memory state. 

This function can be split into three functions: unmapping a memory reference to a 
quantum system (this is done by the function unmapQ 8 ), unmapping a memory reference to 
a channel (unmapch), an d unmapping a memory reference to a channel end (unmapchE 10 )- 

The function unmapQ is designed to obey the following rule: When unmapping a reference 
to a quantum system p then any memory reference which refers to any part of p is unmapped 
too. 

The function unmapch is designed to obey the following rule: When unmapping a refer- 
ence to a channel c then any memory reference to its ends is unmapped too. The reason is 
that when a process sends away a channel, it also loses control over both its ends. 

The function unmapchE is designed to obey the following rule: When unmapping a 
reference to a channel end c then we unmap any memory reference to the corresponding 
channel. The justification is that when a process sends away a part of a channel, it also loses 
control over the whole channel. 

Definition 7.7. We define a function unmap n( i : Refi X LMS —* LMS for unmapping a 
reference to a non-duplicable value from the local memory: 



unmap n d((refType, n), Ims 



del 



unmapQ^n, Ims) if refType = Quantum, 

unmapch( n , Ims) if refType = Channel, 

unmapchE^i, n , Ims) if refType = ChannelEndi 

Ims otherwise. 



where 

• Function unmapQ : (Nj_)[qi x LMS — > LMS is defined as: 

unmap Q (n, (lmsci,lms Q , lms C h, lms C hE)) = (Imschlmsg, lms C h, lms C hE)- 
where Ims'g is defined as: 

Ims' ((Quantum I)) = \ lms Q^Q uantum ^ 1 )) l f set [0]( n ) n set [O](0 ^ 

1 _L otherwise, 

• Function unmapch '■ N x LMS — > LMS is defined as: 

unmap C h(n, (lms C i, lms Q , lms C h, lms C hE)) = (lms C i,lmsQ, lms' Ch , lms' ChE ). 



where lms' Ch = lmsch[(Channel,n) \— > _L], 

lms' ChE = lmschE[(ChannelEndo,n) t— > _L, (ChannelEndi, n) \— > _L], 



7 The name unmap„d should be read as "unmap (a reference to a) nonduplicable (value)" 
8 The name unmapQ should be read as "unmap (a reference to a) guantum (value)". 
9 The name unmapch should be read as "unmap (a reference to a) channel (value)" . 
10 The name unmapchE should be read as "unmap (a reference to a) c/iannel end (value)" 
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• Function unmapchE : {0, 1} x N x LMS — > LMS is defined as: 

unmapchEih n, {lms C i,lms Q , lms C h, lrns C hE)) = (Imsci, ImsQ, lms' Ch , lms' ChE ). 

where lms' Ch = lmsch[(Channel,n) i— ► _L], 

lms ; Q hE = lmschE[(ChannelEndi, n) i— > _L]. 

We extend the function unmap n d so that we can also use any set of references as the first 
argument. 

Definition 7.8. For any i? = {n, . . . , r^} C Refi we define: 

unmap n d(R, Ims) = unmap n d{ri,unmap n d{r2, ■ ■ . unmap n d(r k , Ims) ...)). 

Next, we define a function for updating updating a local memory state Ims = 
(lmsci,lmsQ,lmschJ ms ChE)- We use the existing concept of partial function update and 
extend this concept to local memory states. The extended function updates appropriate 
element of the quadruple according to memory reference type: 

Definition 7.9. Let Ims = (lmsci,lmsQ,lmsch^ ms ChE) be a local memory state. For 
r S Refi and v e Values, we define local memory state update lms[r i— > u]+ as: 



lms[r 



(lms C i[r h-> v]+, lmsQ,lms C h, lms C hE) if re Refci, 

(lms C i,lmsQ[r h-> v]+,lmsch,l™>schE) if r e Ref Q , 

(Imsci, ImsQ, lms C h[r >-> v]+, lms C hE) if r € Refch, 

(Imsci, ImsQ, Imsch, lms C hE[r ^ v] + ) if r £ RefchE- 



7.6 Functions for handling aliasfor constructs 

Quantum algorithms often use multipartite quantum systems. LanQ allows definition of 
compound quantum systems using aliasfor construct: if qo,...,q n are quantum variables 
then the declaration: 

q aliasfor [q , . . . ,q n ]; 

declares a new quantum variable q which specifies a quantum system composed from subsys- 
tems referred by the variables q$, . . . ,q n . In this subsection, we define functions needed to 
handle this construct. 

To simplify the description of the functions in the following text, we first define two 
concepts: We call a quantum variable which was declared using the aliasfor construct an 
aliased quantum variable. The quantum variables not declared using the aliasfor construct 
are called proper quantum variables. 

In the following text, we require that all quantum variables that any aliased quantum 
variable is composed of are proper quantum variables. This requirement is later imposed by 
the semantic rule OP-VarDeclAlF. 

Handling the aliasfor construct is a little complicated. Two cases must be handled when 
assigning a reference to a quantum system to a quantum variable q: 

(1) The variable q is a proper quantum variable. Hence it can be used in several aliased 
quantum variables. Then this variable (la) and all the aliased quantum variables which 
use this variable as their subsystem (lb) must be updated, 

(2) The variable q is an aliased quantum variable. Then all its subsystems must be appro- 
priately modified. However, the subsystems can be also used in several other aliased 
quantum variables as subsystems. Then all these aliased quantum variables must be 
updated too. 
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We define several auxiliary functions which help us with handling the assignment to a 
quantum variable. These functions modify variable properties and a local memory state 
parts of the local process configuration. Therefore all these auxiliary functions take the 
unmodified variable properties vp and local memory state Ims parts as arguments and yield 
the modified ones. Moreover, all these functions take the name name of the quantum variable 
being assigned and the assigned reference ref as its additional arguments. 

The simplest case is the case (la). For this case, we define a function fassignQSystemDirect 
which performs the following operation: 

• If the assigned reference ref = {Quantum, q) is invalid (this is checked by the condition 
linearizej_(g) = -L), the reference ref is unmapped from the local process memory. 

Otherwise the reference ref is set to map from the local process memory to a global 
reference to the corresponding quantum systems in the system memory, 

• The assigned quantum variable is mapped to the reference ref . 

Definition 7.10. We define a function fassignQSystemDirect '■ LMSq x VarProp x Names x 
Re-fQ ~^ LMSq x VarProp as: 



To update all the aliased quantum variables which use the assigned proper quan- 
tum variable as their subsystems (the case (lb)), we first define an auxiliary function 
fassignQSysteminAUas which updates one subsystem reference in the aliased quantum vari- 
able. This function takes one more argument - the index index of the updated subsystem. 
It then proceeds as follows: 

• It takes the original reference of the aliased quantum variable var Ref {name) and modi- 
fies its index-th element to point to the newly assigned system (specified by the recursive 
N-list q). Individual elements of the recursive N-list specifying the new reference are 
denoted by v'j, 

• It unmaps the original reference from the local process memory, 

• If any of the systems in the newly assigned reference is invalid (checked by the condition 
3j : lmsQ{{Quantum,v'j)) = _L), the newly assigned reference is unmapped from the 
local process memory. 

Otherwise the reference ref is set to map from the local process memory to a global 
reference to the corresponding quantum systems in the system memory, 

• The assigned quantum variable is mapped to the new reference {Quantum, [v[, . . . ,v' k ]). 



Definition 7.11. We define a function fassignQSysteminAUas ■ LMSq x VarProp x Names x 
Ref Q x N -> LMSq x VarProp as: 



where lmsQ^ re t 

VPret 

given that ref 




{Quantum, q), 




fassignQSysteminAiias{lmsQ, vp, name, ref, index) = {lmSQ !re t, VPret) 
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9Q 



where lmsQ :Te t = lmsQ[(Quantum, [vi, . . . , Vk]) *— > A-][(Quantum, [v[, . . . , v' k ]) i— ► gq] 
vpret = vp[name t— > (Quantum, [v^, . . . , v' k ])] var 
q if i = index 
vi otherwise 
given that ref = (Quantum, q) 

varRef(name, vp) = (Quantum, [v±, . . . ,Vk\) 

J _L if 3j : lmsQ((Quantum, v'j)) = _L 

1 (GQuantum, linearizej_([f / 1 , . . . ,v' k ])) otherwise 

Before we define a function that handles the whole case (1), we must define one more 
auxiliary function localAliasedVars that returns all the aliased quantum variables available 
to the currently running method. 

Definition 7.12. We define a function localAliasedVars : VarProp — ► ^(Names) as: 

localAliasedVars([Li oq K]) = local AliasedV ar s l(K) 
local AliasedVars(M) = 

where localAliasedVars l '■ VarPropi — ► V (Names) is a function for getting a set of all 
names of variables representing compound systems in the local variable properties list from a 
list of partial function tuples: 

local AliasedV ars L ([K o L (f var , fch, fqa, ftype)]) = dom(f ga ) U local AliasedV ars L (K) 

local AliasedV arsL(D) = 

Now we are ready to define a function fassignQ System that performs assignment to one 
proper quantum variable while correctly adjusting all aliased quantum variables which use 
the variable being assigned (case (1)). The function operates as follows: 

• It first uses the function fassignQSystemDirect to perform the assignment to the proper 
quantum variable, 

• Then it adjusts all the aliased quantum variables which use the variable being assigned 
(the set of such variables is denoted as AQV) using the function fassignQSysteminAUas- 

Definition 7.13. We define a function fassignQ System '■ LMSQxVarPropxNamesxRefQ — > 
LMSq x VarProp as: 

fassignQSystem(lms Q ,vp, name, ref) = (lmsQ, ret ,vp ret ) 
where (lms Qfi , vp ) = fassignQ SystemDirect(lms Q ,vp, name, ref), 

(lmSQ t i,Vpi) = fassignQSystemInAlias(lmSQ yi -i,Vpi-i,qCSi,ref,li)\/i : 1 < i < k, 
lmSQ jre t = ImSQ^k, Vp re t = vp k , 

given that AQV = {aqv £ local AliasedV ars(vp)\ name G set(aliasSubsyst(aqv,vp)}, 
AQV is indexed by numbers i £N : 1 < i < k, 
aqvi 6 AQV, 

aliasSubsyst(aqvi, vp) = [aqv^i, ... , aqv itmi ], 
a Q v i,k = name. 

Last, we define a function fassignQ Alias that performs an assignment to an aliased quan- 
tum variable. This function operates very straightforwardly - it takes each proper quan- 
tum variables which the aliased quantum variable is composed of and applies the function 
fassignQ System onto it. We assume that the number of subsystems of the aliased quantum 
variable corresponds to the structure of the assigned reference (the length of the N-list in the 
reference) . 
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Definition 7.14. We define a function fassignQ Alias '■ LMSq x VarProp x Names x RefQ — > 
LMSq x VarProp as: 

fassignQAHasilmsQiVp, name,ref) = (lmsQ iret ,vp ret ) 

where ImsQfl = ImsQ, vpo = vp, 

(lms Qti ,vpi) = fas S ignQSystem(linsQ : i-i,vpi-i,qi, (Quantum, Vi)) for alll<i<k, 

lmSQ^ re t = lmSQ )k , Vp re t = Vp k , 

given that aliasSubsyst(name, vp) = [qi, . . . , qk], 
re f = (Quantum, [v\, . . . , Vk])- 

7.7 Internal values 

Expressions evaluate to references and values which in turn are possibly references to global 
memory. Operational semantics uses both values and references so we define internal value 
to be a triplet (ref, val,T) £ Refi X Values x Types written as ((ref,val))j. 

7.8 Transitions 

We define operational semantics in terms of the following relations: 

• — > v - Transitions of expressions to internal values, 

• — > e - Transitions of expressions to expressions - the order of evaluation is encoded 
here, 

• — > s - Transitions of statements, 

• — > re t - Transitions of return statements, 

• — > r te - Transitions of runtime errors, 

• — > r - Transitions of statements to statements, used to rewrite an abbreviated statement 
to the unabbreviated form, 

• — > p - Transitions of processes, 

• — * - This defines probabilistic transitions of processes, < p < 1 is the probability of 
the transition. 

We define relation — ► as: 

The relations — > v , — > e , — > s , — > re t, — > r t e , — > r and — > define deterministic and 
probabilistic single process evolution. Nondeterminism is introduced by parallel evolution 
of processes - a choice which process gets evolved is nondeterministic. However, there is 
no nondeterminism in the evolution of individual processes even when they are run in par- 
allel with other processes. This is an improvement over existing quantum process algebras 
[LJ04, GN04]. 

In these algebras, there is a nondeterminism arising from resource sharing. Although 
there is no nondeterminism arising from quantum resource control, there is one arising from 
channel resources: it is possible for three or more processes to share one channel. When 
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these processes use the channel simultaneously, the resulting behaviour is non deterministic. 
We avoid this type of nondeterminism by using channel ends for communication instead of 
the channels themselves and imposing a constraint that one channel end is owned by exactly 
one process at one time. This approach was also studied in the context of 7r-calculus in 
[KPT96, GH05]. 

When probabilistic and nondeterministic choice are to be evaluated simultaneously, we 
must decide which choice is resolved first. We have taken the same approach as other authors 
(eg. [GN04]): the nondeterministic choice is resoved first. 

When we get to the situation when no rule is applicable to the configuration, the con- 
figuration becomes stuck. Because LanQ is a typed language, the errors arising from invalid 
typing can be avoided. The formal proof that a language does not suffer from typing errors 
lies in proving standard lemmata in the style of Wright and Felleisen [WF94]. For LanQ, this 
is done in Section 8. 

However, there exist some unavoidable cases caused by the by-reference handling of vari- 
ables. For example, a process P can send away a qubit referred by variable ip. If P later tries 
to measure a qubit referred by t/j, there is none. Such cases are handled by runtime errors 
described in the next subsection. 

7.9 Runtime errors 

There exist errors that cannot be recognized during compile time and can occur during the 
run time. For that reason, we define special stack symbols representing such runtime errors: 

• UV: an error representing an uninitialized variable usage. An example method invoking 
this error is in Figure 13(a) (U is a unitary operation there). In this example, the variable 
q is sent away, hence not initialized. The attempt to perform U(q) therefore invokes a 
runtime error UV. 

• OQV: an error representing overlapping guantum variable usage. An example method 
invoking this error is shown in Figure 13(b) (U is a two-qubit unitary operation there). 
In this example, variables p and q refer to the same quantum system. An attempt to 
perform U(p,q) therefore invokes a runtime error OQV. 

• ISQV: an error representing an assignment to an incompatibly structured guantum 
variable. An example method invoking this error is shown in Figure 13(c). In this 
example, variables p and q refer to qubit systems, r refers to a system composed of 
the two qubits. An attempt to assign one four-dimensional quantum system to r fails 
as this assignment must also appropriately set the two systems p and q. Hence this 
assignment invokes a runtime error ISQV. 



7.10 Processes and configurations 

In this subsection, we define special configurations, processes and relations between them. 

We define a special configuration start (a starting configuration for any LanQ program 
execution) and a set C of silent local process configurations as: 

start d = f [(((!),[]), Q)| ((Q,0, 0,Q), ■ > mamQ )] 

Oc = {(lms,vp, e) | Iras G LMS,vp E VarProp} 

11 Note however that we can take advantage of the nondeterministic behaviour: It can be used eg. to simply 
catch server environment serving requests from multiple clients where it is used to resolve which request came 
from which client. 
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void exi(channelEnd[qbit] c) { void ex2{) { void ex3() { 



qbit q; qbitp,g; qbitp,g; 

q = new qbit(); q = new qbitQ; r aliasfor \p,q]; 

send(c, q); p = q; r = new Q4O; 

U(q); U(p,q); } 

(c) 

(a) (b) 



Figure 13: Example methods invoking runtime errors. 



The terminal configuration is defined as 

[gs\(lmsi,vpi,vi) \\ ■ ■ ■ \\ (lms n , vp n , v n )] 



where gs is a global part of the configuration, and for all i, Imsi £ LMS, vpi £ VarProp, 
and Vi is either s, runtime error RTErr, or an internal value v. If some of Vi is a runtime 
error, then we call this configuration errorneous. 



7.10.1 Structural congruence 

In this subsection, we define structurally congruent processes. A process is fully character- 
ized by a local process configuration, therefore the relation is defined on these local process 
configurations. 

Any process is structurally congruent to a process running in parallel with a silent process 
(rule SC-Nil). Order of processes in the configuration does not matter (SC-Comm) as well 
as grouping of processes within the configuration (SC- Assoc). 



SC-NlL P || = P for any G C 

SC-Comm P\\Q = Q\\P SC-Assoc (P || Q) || R = P || (Q || R) 



7.10.2 Nondeterminism and parallelism 

In this subsection, we define behaviour related to nondeterminism and parallelism. 

The rule NP-PropagProb states that evolution of a process P leaves all other processes 
running in parallel with P in their original state while propagating the probability distribution 
on configurations to the top level. We can exchange congruent processes without any impact 
on the resulting behaviour (rule NP-Cong). A probabilistic configuration consisting of two 
or more probabilistic alternatives must resolve a probabilistic choice (rule NP-ProbEvol). 



NP-PropagProb [9S 1 P] ^^P>* k« I P ^ 



NP-CONG 



[gs I P || Q] — ► Si Pi • [g Si \ Pi \\ Q] 
[gs I P) — ► ffl; pi • [gs t I P] P = P' P = P[ for all i 



[ gs I P i] — > EBj pi • [g Sl I P/] 
NP-ProbEvol m q i=% pi • [g Sl I P] [gst \ Pi] for q > 1 
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7.11 Evaluation 

In this subsection, we define the transition rules of individual processes. 
7.11.1 Basic rules 

The first four rules define configuration change on a skip statement (rule OP-Skip), a variable 
(OP-Var) and bracketed expression (OP-Bracket). Next rule (OP-BlockHead) is used 
to evaluate sequence of statements from first to last. Last two rules (OP-SubstE and OP- 
SubstS) defines substitution of evaluated expressions. 

OP-Skip [gs \ (lms,vp,i ts)] — > s [gs\ (lms,vp,ts)] 

OP-Var [gs | (Ims, vp, x ts)] — ►„ 

[gs | (Ims, vp, ( (ref, Ims(ref))) tyve0f{r vv ) ts)} 
where ref = varRef(x, vp) 

OP-Bracket [gs | (Ims, vp, ( 

OP-BlockHead [gs | (Ims, vp, 
OP-SubstE [gs | (Ims, vp, v 

OP-SubstS \qs I (Ims, vp, v 



ts)] 


[gs | 


(Ims, 


vp, E ts)] 


ts)} - 


[gs \ 


(Ims. 


vp, head(Be) tail (Be) ts)] 


ts)] - 


[gs | 


(Ims, 


vp, Ec[v] ts)] 


ts)} - 


^ e [gs \ 


(Ims, 


vp, Sc[v] ts)] 



7.11.2 Promotable expressions 

Promotable expressions are expressions that can be turned into statements by appending a 
semicolon. The expression is evaluated (rule OP-PromoExpr) but the resulting value is 
then forgotten (rule OP-PromoForget). 



OP-PromoExpr [gs | (Ims, vp, PE\ ts)] — > e [gs \ (Ims, vp, PE ts)} 
OP-PromoForget [gs | (Ims, vp, vj ts)] — > s [gs \ (Ims, vp, ts)] 



7.11.3 Allocation 

Allocating a resource is performed by an evaluation of expression "new TQ" where T is a 
type of the resource, ie. a type of a channel or a quantum system. Type of quantum systems 
of dimension d are denoted by Qd, eg. qbit = Q2. 

Allocation of a channel resource is handled by rule OP-AllocC, quantum resource allo- 
cation is handled by rule OP-AllocQ. 
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OP-AllocQ [gs | (7ms, vp, new QhQ ts)] — > v 

[gs' | (Ims 1 , vp, (((Quantum, [I]), (GQuantum, [/])))Q d ts)] 
where I = \L\ 

gs' = (( P ®(\l d ),L-[d]),C) 
Ims' = (Imscu ImsQ, lms C h, ImschE) 
Ims'q = lmsQ[(Quantum, [I]) i— > (GQuantum, [I])] 
given that gs = ((p, L),C) 

Ims = (Imsci, ImsQ, lms C h, ImschE) 

OP-AllocC [gs | (Ims, vp, new channel[T]Q ts)] — ►„ 

[gs' | (Ims' , fp, (((Channel, I), (GChannel, I))) rh* nn°\ [T] ^ s )\ 
where I = \C\ 

ga > = (Q,C-[c \=\c 1 ]) 

Ims' = (lmsci,lmsQ,lms' Ch ,lms' ChE ) 

lms' Ch = lmsch[(Channel,l) t— > (GChannel, I)] 

lms' ChE = lmschE[(ChannelEndo, I) t— > (GChannel, I), 

(ChannelEnd\,l) i— > (GChannel, I)] 

given that gs = (Q, C) 

/t7t,s = (ImschlmsQ, Imsch, lms C hE) 



7.11.4 Variable declaration 

Variable declaration is an addition of a variable to the innermost list of mappings of variable 
names to references. We consider any variable declaration of multiple variables of the same 
type: T a, b, c; to be an abbreviation of T a; T b; T c;. 

For declaration of a quantum compound system a construction q aliasfor [qo, ■ ■ ■ ,q n ] is 
used where qo, . . . ,q n are names of quantum variables. Some of them can again be compound 
systems. To deal with this feature, all variables from {qo, . . . , q n } that represent compound 
systems are expanded. This can be seen from the following example - we require the decla- 
rations on the left and right side to be equivalent: 

qbit qo,qi,p; qbit q , qi,p; 

q aliasfor [q , q{] ; q aliasfor [q , q{] ; 

r aliasfor [p, q\; r aliasfor [p,qo,qi]', 
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OP-VarDeclMulti [gs \ (Ims, vp, T x, I; ts)] — > r 

[gs | (Ims, vp, T x; T I; ts)] 

OP-VarDecl [gs | (Ims, [vpg og [vp or, vpr]], T x; ts)] — > s 

[gs | (Ims, [vp G o G [vp o L vp' L ]],ts)] 
where vp' L = vp L [x h-> none] +i „ ar [x h-> T] +jtype 

OP-VarDeclChE 

[gs | (Ims, [vpg °g [vp °l vpr]], channel[T] c withends[cn,ci]; ts)] — > s 

[gs | (Ims, [vp G o G [vp o L vp' L ]],ts)] 
where vp' L = vp L [c h-> none] +i „ ar [c h-> none]+ )t , or [ci i-> none] +]t)ar [c h-> (c ,ci)] +jC h 

[c i ^ channel[T]] +)t2/pe [co h-> channel End [T]] +itype [ci >-> channel End [T]] +it yp e 

OP-VarDeclAlF [gs | (Ims, [vpg °g [vp°r, vpr]], Q aliasfor [go, . . . ,q„J; ts)] — > s 

[gs | (Ims, [vp G o G [vp o L vp' L ]],ts)] 
where vp' L = vp L [g h-> (Quantum, [l , l n ])]+,var[q [gd, • • • , ^nll+.ga 

J Z if varRef l(<H, [vp °l vpl]) = (Quantum, I) 
I _L otherwise 

, _ \po, ...,p k if aliasSubsyst L (qi, [vpo L vp' L ]) = [p , . . . ,p k ] 
I qi otherwise 
varRef l(q%, [vp °l v p'l\) 1S defined for < i < n 



given that Zj 



7.11.5 Assignment 

Assignment command x = E has to be divided into two rules: one where expression e is evalu- 
ated (OP- AssignExpr) and the other where the result of evaluation of e is bound to variable 
x and possibly stored into memory (rules OP- AssignNew Value and OP-AssignValue). 
The value is stored into memory if it was not there yet what is indicated by reference part of 
the internal value equal to none. 

Assigning a quantum system to a variable can be complicated when the variable was 
declared using the aliasfor construct. For example, let tp be a variable that represents a 
quantum system composed of systems ipA. and ips (it was declared as: tp aliasfor [ipA,tpB])- 
Assigning a value to ip must appropriately modify both ipA an d ipB an d can be only per- 
formed if the assigned value represents a compound system made of two subsystems (rule 
OP-AssignQAValue). Similarly, assigning a value to ipA must also modify ip (rule OP- 
AssignQ Value). If the structure of assigned system is not compatible with the structure of 
the assigned variable then a runtime error ISQV occurs (rule OP-AssignQAValueBad). 
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OP-AssignExpr [gs \ (lms, vp, x = E ts)] — > e [gs \ (lms, vp, E x = • ts)] 

OP-AssignNewValue [gs \ (lms, vp, x = v ts)] — ►„ [gs \ Urns', vp', ((lr', lv))r ts)] 
where lr' = (Classical, nc) 

lms' C i = lmsci[lr' i— > lv] + 
vp' = vp[x i ^ Zr'Juar 
given that v = {{lr, lv))j 

nc £ No is such that lms((Classical,nc)) is not defined 
lms' = lms[lr' lv] + 
lr = none A Iv ^ _L 

OP-AssignQValue \qs \ (lms, vp, x = v ts)] — [gs | (Ims', vp' , v ts)] 

where (lms' Q ,vp') = f ass ig n QSyste m (lmsQ,vp,x,lr) 
given that v = ((lr, lv))j 

lr = (Quantum, q) and aliasSubsyst(x, vp) is not defined 
lms = (Imsci, ImsQ, lms C h, lms C hE) 
lms 1 = (lms C i,lms' Q ,lmsch,lmschE) 

OP-AssignQAValue [qs \ (lms,vp, x = v ts)] — > v [gs\(lms' ,vp' ,y_ts)] 

where (lms' Q ,vp r ) = f a ssignQAlias(lms Q ,vp,x,lr) 
given that v = ((lr, lv))j 

lr = (Quantum, q) and alias Subsyst(x, vp) is defined 
lms = (lms C i,lmsQ,lms C h, lms C hE) 
lms' = (Imsci, lms' Q , lms C h, lms C hE) 
typeOf(q) = (g)? =0 Q % , T = <g)™ „ 2} 
and m = n and Mi : Qi = Tj 



OP-AssignQAValueBad [qs | (lms,vp, x = v ts)] — > rie [gs | (lms, vp, ISQV)] 

given that typeOf(q) = <g)" =0 Qi, T = ®j=o r j 
and m ^ n or 3i : Qj ^ Tj 



OP-AssignValue [qs | (7ms, x = y ts)] — ►„ [gs \ (lms, vp', v ts)] 

vp[x i — ► Zr]„ ar [xo i— > (Channel Endo, i)] va r[xi l— > (ChannelEnd\,i)] var 
where vp' = < if Zr = (Channel, i) and chanEnds(x,vp) = (xq,xi) 

^vp[x i — > /r]„ ar otherwise 
given that v = ((/r, )) j 

(Zr = none A = _L) V (Zr 7^ (Quantum, q)) 



7.11.6 Block 

Block command is used to limit scope of variables and to execute multiple statements: 
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OP-Block [gs | (Ims, [vp G o G vp] , {B} ts)] — > s 

[gs] (Ims, [vp G o G [vp o L □]], B ts)] 

OP-BlockEnd [gs\(lms,[vp G o G [vpo L vpi\],9i L ts)] — > s 

[gs\(lms, [vp G o G vp],ts)} 



7.11.7 Conditional statement — if 

Conditional expression if (E) S\ else S2 has to be split into three rules: one where the 
condition is evaluated (OP-IfExpr) and rules for reduction when the condition evaluates to 
true (OP-IfTrue) and false (OP-IfFalse). 



OP-IfExpr [gs \ (Ims, vp, if (E) S-\ else S<?, ts)] — > e (lms,vp,E if (•) S-\ else S9. ts)] 

OP-IfTrue [gs I (Ims, vp, if (v) 5*1 else S?, ts)] — > s [gs \ (Ims, vp, S± ts)] 

if v = ((r,true)) boo | 

OP-IfFalse [gs | (Iras, vp, if (v) S^ else ts)] — > s [gs \ (Ims, vp, ts)] 

if v = ((r, false)} bool 



7.11.8 Conditional cycle — while 

While is syntactically converted to a corresponding if statement. 



OP-While [gs I (Ims, vp, while (E) S ts)] — > T 

[gs I (Iras, vp, if (E) {S while (E) S} else ; ts)] 



7.11.9 Method call 

Call of a method m whose parameters are expressions is rewritten to a call of method m 
whose parameters are values. Parameters passed to the method are evaluated in the original 
variable context vp (rule OP-MethodCallExpr). 

The call of the method m with value parameters is evaluated in two different ways de- 
pending on whether m represents a classical method or a quantum operator. 

In the case when m represents a classical method, the call of a method m is rewritten to 
the unwound body of method m (rule OP-DoMethodCallCl) translated to the internal 
syntax by Mb taken from method typing context. 

If m represents a quantum operator £ m , the operator £ m is applied to a quantum subsystem 
specified by the parameters vi = {{r±, «i))ti> • • • j @v„ = ((r n ,v n ))j u . Values v\,...,v n are 
either global references to quantum storage (GQuantum,l ri ), . . . , (G Quantum, I Tn ) or _L. In 
the case when _L is referred, a run-time error UV occurs (OP-MethodCallQUninit). 

The condition that all manipulated quantum system are physically different can be refor- 
mulated as: all the indices in lists l ri , . . . , l Tn are mutually different, ie. setrQi (l rj )nset[Q] (l Tk ) = 
and |^r,-|[0] = I se t[o](^j)l f° r au 1 — — n i J 7^ If this condition is not satisfied, runtime 
error OQV is invoked (OP-MethodCallQOverlap). 
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The list qsi of indices of quantum systems to be measured is given by a concatenation 
of individual linearized lists: qsi = l ri - . . . -l Tn , which determines quantum system q qs i. Di- 
mension dq qsi of the quantum system qi is calculated from the global part ((p,L),C) of the 
configuration as 

\qsi\ 
i=l 

We denote d the order of matrix p and d the dimension of untouched part of the system, 
d = d/d qqsi (rule OP-DoMethodCallQ). 



OP-MethodCallExpr [qs \ (Ims, vp, m(v,E,E) ts) — > e 

[gs | (Ims, vp, E m(v, • ,E) ts)] 

OP-DoMethodCallCl [gs \ (Ims, vpg, m(vi , . . . ,v n ) ts) — > e 

[gs | (Ims', [vp G o G [□ o L vp']],M B (m) o^ts)] 
where vp' = (\a\ i-> r[, . . . , a n h-> r' n ], [],[], [ai h-> Ti, . . . , a n (-> T n ,@retVal i-> T]) 

Ims' = lms[r[ i— ► v±]^ [r' n t— > t>„] + 

given that vi = ((n, Vi)) Tl , ■ ■ • , v n = ((r n , w n )) Tn 
J (Classical, nci) if rj = none 
rj otherwise 
where all ncj are mutually different natural numbers 

such that lms((Classical,nci)) is not defined 
m represents a classical method and 
T m(Ti ai,...T n a n ) is a header of method m 

OP-MethodCallQUninit [gs \ (Ims, vp, m(vi , . . . ,v n ) ts)] — > r te 

[gs | (Ims, vp, UV)] 
given that vi = ((n, wi))td • • • > v « = (( r ^ y n))T n 
3i : v j = _L 

OP-MethodCallQOverlap [qs \ (Ims, vp, m(v^ , . . . ,v n ) ts)] — >. rte 

[gs | (Ims, vp, OQV)] 
given that vi = ((ri, «i))ti, • • • , v„ = {{r n ,v n ))r n 

v\ = (GQuantum, l ri ), . . . ,v n = (GQuantum, l Tn ) 
setr^)](Irj) n setfQ](Z rfc ) ^ for some 1 < j, k < n, j ^ k 
or 

I [o] I set [o](^j)l for some i < i < n 
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OP-DoMethodCallQ [gs \ (Ims, vp, m(vi ,v„) ts)] — > v 

[gs' | (1ms, vp, {{none, ±)) vn ; ri ts)] 

where gs' = ((p', L),C) 

ft = n T (£ m ® i d -(n P n T ))n 

given that vi = ((n, Ui))t 15 • • • , v n = ((r„, u n )}T n 
5S = ((p,L),C) 

= (GQuantum, l ri ), ■ ■ ■ ,v n = (GQuantum, l rn ) 
set[yj(Z r .) n set[Q](i rfc ) = for all 1 < j, k < n, j / k 

IM[0] = I set [0](^j)l for all 1 < j < n 

II is a permutation matrix which places affected quantum 

systems to the head of p in the order given by vi, . . . , v n 
m represents a quantum operator £ m 



7.11.10 Returning from a method 

When a method evaluation finishes, the control is passed back to its caller. The place 
where the called method was invoked by the caller is marked by the oj^ symbol (see OP- 
DoMethodCallCl). If a method returns no value, it can either end without return state- 
ment just by evaluating the last statement in the method (handled by OP-ReturnVoidImpl) 
or by explicit return; statement. In that case the return; statement pops everything from 
the term stack until it finds the symbol oj^ (OP-ReturnVoid). When the method re- 
turns a value, the return value is evaluated first (OP-ReturnExpr) and then the return 
value is then left on top of the stack after popping all symbols up to o M from the stack 
(OP- Return Value). 



OP-ReturnVoid [gs \ (Ims, [vpc °g vp] , return; tsM 2M ts)] — > re t 

[gs | (Ims, vp G , ((none, -L)) uniH ts)] 

where tsM does not contain o M 

OP-ReturnVoidImpl [gs \ (Ims, [vpc °g vp], om ts)] — > s 

[gs | (Ims, vp G , {{none, -L))„ n iH ts)] 

OP-ReturnExpr [gs \ (Ims, vp, return E\ ts)] — > e 

[gs | (Ims, vp, E return • ; ts) 

OP-Return Value [gs \ (Ims, [vpn °n up], return v; tsu Qivt ts)] — > re t 

[gs\ (lms,vp G ,y_ts)] 
where tsM does not contain o M 



7.11.11 Forking 

Forking creates a new process which is started from given method. As fork contains a method 
call construct, the rule OP-ForkExpr for evaluation of arguments is similar to the rule OP- 
MethodCallExpr. In the rule OP-DoFork, a new process is started, values passed as 
parameters to the forked method are copied to the new process memory. The non-duplicable 
values passed as parameters to the forked method are unmapped from the parent process 
memory. 
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OP-ForkExpr [gs\ (Ims, vp, fork m(v,E,E); ts)] — > e 

[gs | (Ims, vp, E fork m(v, • ,E); ts)] 

OP-DoFork [gs | (Ims, vp, fork m(^r^ , . . . ,v„); ts)] — > p 

[ffsKZm^jUpjts) || (lmsl,,M, i m(y' 1 v^ ))] 

where Ims'j = unmap n d({r\, . . . , r n }, lms\) 

lms' 2 = (MAUWi"v 1 ) + ...[r' n »v n } + 

given that vi = {{n, Vi)) Tl , . . . , v n = ({r n ,v n )) Tn 
I (Classical, nci) if rj = none 
I rj otherwise 
where all ncj are mutually different natural numbers 
such that lms\((Classical,nci)) is not defined 



7.11.12 Measurement 

Measurement is performed when measure(6, e\, . . . ,e n ) primitive method is evaluated. Its 
first argument b determines measurement basis, the other arguments determine quantum 
systems that are to be simultaneously measured. Arguments e\, . . . ,e n evaluate to internal 
values vi = ((n, i>i))ti) • • • } v n = ((r n ,v n ))j n . Values v\,...,v n are either global references 
to quantum storage (GQuantum,l ri ), . . . , (G Quantum, I rn ) or JL. In the case when _L is 
referred, a run-time error UVoccurs (OP-MeasureUninit). 

The condition that all the measured system are physically different can be reformulated 
as: all the indices in lists l ri , . . . , l Tn are mutually different, ie. setj^](/ rj ) nsetrQ](Z rfc ) = and 
mi[0] = l se t[0](^j)l ^ or au ^ — J> ^ — n ' J / k. If this condition is not satisfied, runtime 
error OQV is invoked (OP-MeasureOverlap). 

The list qsi of indices of quantum systems to be measured is given by a concatenation 
of individual linearized lists: qsi = l ri - . . . -l rn , which determines quantum system q qs i. Di- 
mension d qqsi of the quantum system qi is calculated from the global part ((p,L),C) of the 
configuration as 

\qsi\ 

dq qsi = ^2 Lqsii ■ 
i=l 

We denote d the order of matrix p and d the dimension of unmeasured part of the system, 
d= d/d qqat . 

In quantum mechanics, the possible results of the measurement are eigenvalues of the 
observable. We assign to each eigenvalue an index in a list of all eigenvalues. This index is 
returned as a result of evaluated measure expression. Indeed, it is possible that two or more 
eigenvalues are the same (they are called degenerate eigenvalues). In this case, the obtained 
result is the first index of corresponding eigenvalue in the list. The list is indexed from zero. 

Now we can formulate rules for measurement: 
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OP-MeasureExpr [gs | (lms, vp, measure(v, E,E) ts] — > e 

[gs | (lms, vp, E measure(v, • ,E) ts)} 

OP-MeasureUninit [gs \ (lms, vp, measure (v^,vi , . . . ,v n ) ts)] — > r t e 

[gs | (lms, vp, UV)] 
given that vi = ((ri,vi)) Tl , . . . , v n = ((r n , v n )) Tn 
3i : Vi = JL 

OP-MeasureOverlap [gs \ (lms, vp, measure(v),, vi , . . . ,v n ) ts)] — > r t e 

[gs | (lms, vp, OQV)] 
given that vi = ((n, vi)) Tl , . . . ,v n = {{r n ,v n ))j n 

v\ = (GQuantum, l ri ),..., v n = (GQuantum, l Tn ) 
set\0\(l rj ) n set[Qi(/ rfc ) 7^ for some 1 < j, k < n, j ^ k 
or 

|/ rj |[Q] ^ | setryi(Z rj .)| for some 1 < j < n 

OP-DoMeasure [gs | (lms, vp, measure (v/),vi , . . . ,v n ) ts)] — > v 

Hi Pi • [gsi | (lms, vp, {{none, fdi(i)))\„, ts)} 

where gsi = ((pi,L), C) 

Pi = tv [n T (Pi ® / J )n P n T (p i ® i d -)tn] 
_ n T (p, ^ j^npgXg ^ j d -)tn 

Pi — 

Pi 

fdi(i) is the first index of z-th eigenvalue in the list of 

observable eigenvalues (for the case of degenerate eigenvalues) 
given that vi = ((ri, v x )) Tl , . . . , v„ = ((r n , v n )) Tn 

vi = (GQuantum, l n ),..., v n = (GQuantum, l Tn ) 
gs = ((p,L),C) 

set[Q](/ rj ) n set[Q](Z rfc ) = for all 1 < j, k < n, j ^ k 

IM[0] = I set [0](^ )l f° r all 1 < j < n 

AiPj is a spectral decomposition of a measurement in 

the basis given by v;, 
II is a permutation matrix which places measured quantum systems 

to the head of p in the order given by vj , . . . , v n 



7.11.13 Communication 

Communication is performed when there is one process sending a value over a channel end and 
another process waiting to receive a value over a channel end provided that both channel ends 
belong to the same channel. This condition is equivalent to the condition that both channel 
ends refer to the same channel. First three rules (OP-SendExprI, OP-SendExpr2 and 
OP-RecvExpr) are to evaluate statement arguments and the rule OP-SendRecv performs 
the communication. When either the sending channel end or the sent value is undefined, or 
a receiving process attempts to receive from uninitialized channel end, a runtime error UV 
occurs (rules OP-SendUninit and OP-RecvUninit). 

Unique ownership of resources (both quantum and channel) is ensured by unmapping 
them from the local memory of the sender process using the function unmap n d- 
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OP-SendExpr.1 [gs \ (Ims, vp, sendfE^ , E?); ts)] — > e 

[gs | (Iras, vp, Ex send(», E?); ts] 

OP-SendExpr2 [qs\ (Ims, vp, send(v r , E); ts)] — > e 

[gs | (Ims, vp, E sendfv^, •); ts] 

OP-SendUninit [gs | (Ims, vp, sendfvi , V2); ts)] — > r te [gs \ (Ims, vp, UV] 

given that vi = ((ri,vi)) Tl and v\ = _L or v 2 = ((r 2 ,v 2 ))j 2 an d v 2 = -L) 

OP-RecvExpr [gs \ (Ims, vp, recv(E) ts)] — > e [gs | (Ims, vp, E recv(») ts] 

OP-RecvUninit [gs \ (Ims, vp, recv(v) ts)] — > rte [gs \ (Ims, vp, UV] 

given that v = ((r, v))j and v = _L 

OP-SendRecv [gs \ (Ims] , vp^ , send(v ffl , v P ); tsi ) || (Ims?,, vp?,, recv(v r , 2 ) ts?)] — > p 

[gs\(lms' 1 ,vpi,tsi) \\ (lms' 2 ,vp?, ((lr' 2 ,lv' 2 ))T ts?)] 
where Ims^ = unmap n( i(sentRef,lmsi) 
lr\ if sentRef 6 Ref n d 
none otherwise 



lv' 2 = sentVal 



lms 2 



lms2[sentRef 1— > sentVal] if sentRef 6 Ref n d 
lms2 otherwise 
given that v e = ((sentRef , sentVal)) j 
v Cl = ((ciRef,ciVal)) T 
v C2 = ((c 2 Ref,c 2 Val)) T 
c\Ref / none and c 2 Ref 7^ none 

ciVal = c 2 Val (both ends refer to the same channel) 



7.12 Rule index 

— > e : OP-AssignExpr, OP-DoMethodCallCl, OP-ForkExpr, OP-IfExpr, OP- 
MeasureExpr, OP-MethodCallExpr, OP-PromoExpr, OP-RecvExpr, OP- 
ReturnExpr, OP-SendExprI, OP-SendExpr2, OP-SubstE, OP-SubstS 

— > p : OP-DoFork, OP-SendRecv 

— > r : OP-BlockHead, OP-Bracket, OP-VarDeclMulti, OP-While 
— > ret : OP-ReturnValue, OP-ReturnVoid 

— > rte - OP-AssignQAValueBad, OP-MeasureUninit, OP-MeasureOverlap, OP- 
MethodCallQUninit, OP-MethodCallQOverlap, OP-RecvUninit, OP- 
SendUninit 

— > s : OP-Block, OP-BlockEnd, OP-IfFalse, OP-IfTrue, OP-PromoForget, OP- 
ReturnVoidImpl, OP-Skip, OP-VarDecl, OP-VarDeclAlF, OP-VarDeclChE 

— OP-AllocC, OP-AllocQ, OP-AssignNewValue, OP-AssignQAValue, OP- 
AssignQValue, OP-AssignValue, OP-DoMeasure, OP-DoMethodCallQ, 
OP-Var 
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In this section, we prove type soundness (see eg. [WF94]) for LanQ. 

To prove type soundness (also known as Subject reduction) theorem, we first define typing 
on configurations. Then in series of progress lemmata proofs, we prove that any typable 
configuration can be reduced by some semantic rule. After this proof, we prove series of type 
preservation lemmata stating that if a configuration gets reduced to another configuration, 
either a runtime error occurs or the type of the configuration is preserved. These lemmata 
straightforwardly imply type soundness of the language. 

However, we cannot prove the type soundness property for the unrestricted language 
because it is possible that a program gets to a stuck configuration during the evaluation. This 
can happen because the send and recv constructs are blocking and synchronizing actions. 
Consider a process which attempts to send a value over a channel where no other process is 
receiving the values from the other end of the channel. Then no semantic rule can be applied 
to the sending process. Symmetrically, it is indeed possible to define a process which attempts 
to receive a value from a channel where no other process sends a value over this channel. Such 
a process also cannot evolve, therefore the evaluation can get to a stuck configuration. 

In other words, we can prove type soundness only for the noncommunicating part of the 
language. Nevertheless, if to each send statement there is a corresponding recv expression, 
then it can be proved that the evaluation of a well-typed configuration never gets stuck, hence 
type soundness can be proved for the unrestricted language. 

8.1 Typing of configurations 

To prove LanQ type soundness, we follow the approach of [BPP03]. Before proving type 
preservation, we define typing of configurations in this subsection in Figures 14 and 15. 

Any configuration C = [gs \ls\ \\ ■ ■ ■ \\ ls n ] is assigned a type T, written as C : T which is 
a cartesian product of types of local process configurations ls\, . . . ,ls n . If the type of Isi is 
Ti then T = (Ti, . . . ,T n ) (see the typing rule T-Config). 

We call a configuration which is assigned a type a well-typed configuration. 

The typing rules provide rules for well-formedness of configurations, hence also for local 
process configurations. This indeed means that structure of variable properties and a term 
stack are tightly connected: To any block end mark o L on the term stack, the variable 
properties must contain a nonempty list of variable properties [vpoi vp{\ 6 VarPropi (see 
rule TC-BlockEnd); to any method call mark on the term stack, the variable properties 
must contain a nonempty list of lists of variable properties [vpc °g v p] £ VarProp (see rules 
TC-RetHole, TC-RetExpr, TC-RetVoid and TC-RetImpl). 

Typing of local process configurations as depicted in Figure 14 needs a deeper explanation. 
Contrary to usual typing of configurations known eg. from A-calculi where one configuration 
contains only one expression, we deal with the situation where there are many "expressions" in 
one configuration. These expressions are in our case term stack elements and they altogether 
form a term stack of a local process configuration. 

The type of a local process configuration is defined as a — > r for types a, r. The type a 
specifies the type of the hole in the top term stack element, r specifies the type of the result 
value. When there is no hole in the top term stack element, a is void. 

The top term stack element TE can contain at most one hole. As the hole type a is always 
known and the variable typing context can be deduced from variable properties, the type r' 
of TE is derivable from the typing rules defined in Section 5. 

If TE is the only term stack element in the local process configuration, its type determines 
the type of the result value r. Otherwise, the type r' is the type of a hole in the term stack 
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TC-Empty 
tc-runtime 

TC-ExprHole 
TC-StatHole 

TC-RetHole 
TC-ExprClo 
TC-StatClo 



TC-RetExpr 



TC-RetVoid 



TC-RetImpl 



TC-BlockHead 



TC-BlockEnd 



TC-VarDeclMulti 



TC-VarDeclOne 



TC-VarDeclChE 



M ; T \- c (lms,M,s) :t^t 
M\T\-n (lms,vy, RTErr ) : cr -> r 

M; T, vpContext(vp), • : a h*r Ec : r' M; T he (Ims, vp, ts) : r' — > r 
M; r he- (1ms, up, -Be ts) : er — > t 

M; r, vpContext(vp), • : cr hy Sc : void M; T he (Ims, vp, ts) : void — * r 
M; r hp (ims, up, ffc ts) : <t — > r 

if 5c 7^ return • ; 

M;T he (Ims, vpc, ts) : typeOf(@retVal, [vpo o G vp]) — > r 



M; r he (7ms, [upc °g vp] , return 



qtvt ts) : er ► t 



M; r, vpContext(vp) \~t E : r' M; T he (ims, up, ts) : t' — * r 
M; r he (Ims, vp, E ts) : cr — > r 

M; T, vpContext(vp) \~t S : void M; T he (Ims, up, ts) : void — > r 

M; r he {Iras, vp, S_ ts) : a — > r 

if 5 ^ return E;, S ^ return; 

M; r, vpC ontext{[vpQ o G vp]) hy 25 : typeOf(@retVal, [upc °g vp]), 
M; r he (ims, vpa, ts) : typeOf(@retVal, [vpc °c v p])~^ T 

M ; r he (Ims, [upc °c v p] , return E\ . . . q-m ts) : a — > r 

M;T he (Ims, vpa, ts) : void — » r 
M;T he (ims, [upc °g up], return; . . . qm ts) : cr — ► t 

M;T he (Ims, vpc, ts) : typeOf(@retVal, [vpo o G vp]) —> t 
M;T he (Ims, [vpc °c vp]* °ivt ts) : cr — > r 

M; T he (ims, up, -Ben 2jgj . . . Be„ ts) : void — » r 
M; r he (ims, up, -Ben 2jej . . . -Be,, ts) : cr — > t 

M; r he (ims, [upc °g up], ts) : void — * t 
M;T he (ims, [upc °g [vp°L uur,]], oj, ts) : void — > r 

M ; T he (ims, up, T 7 n ; T Jj /„; ts) : void ->■ r 

M; T h c (ims, up, T I n ,h, ■ ■ ■ ,/„; ts) : cr -> r 

varRef(I,vp) is undefined 
M; T he (ims, up', ts) : void — > r 

M; r he (Ims, vp, T I; ts) : a — > r 

where up' = up[7 i-> T] +itype 

varRef(Ii,vp) is undefined for i — 0, ..2, 
Iq,I\,I2 are mutually different, 
M; T he (ims, up', ts) : void — > r 



M; r he (ims, up, channel[r] In withends[/i ^/jjj ts) : a ^ t 



where up' = up[c channel[T]] + tj, pe [co i— > channelEnd[T 



-,type 



[c\ i ► channelEnd[T] 



TC-VarDeclAlF 



varRef(Io,vp) is undefined, 
M; r h-r 2j : Tj T, is a quantum type for i = 1, ..n, 
M; r he (Ims, vp' , ts) : void — * r 

M; T he (ims, up, 7 n aliasfor [Ii , . . . ,/„,]; ts) : cr — > r 

where up' = up[7 i-> (g)^ 1 T|] +)tJ/pe 



Figure 14: Typing rules for local process configurations 
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m „ „ Vi € 1, . . . , q : M; T h GS* i • • • LS* J : r< 

T-MixedConf ' ' v 1 r ^ rr° ^ 1 

M; r h ffif =1 pi • [GSt | || • • • || LSi, n ] 

Vigl n= M;rr- C L5 8 : voider, 

M;Tr- [G5|L5i || ••• || L5 n ] :n™=i^ 

Figure 15: Typing rules for configurations 



element right beneath TE and we can continue with typing the local process configuration 
where TE is popped from the term stack. 

To derive variable typing context from local process configuration variable properties, we 
define a function vpContext. This function is defined as follows: 

Definition 8.1. We define a function vpContext : VarProp — > {Names Types) which 
creates a variable typing context from variable properties as: 

vpContext{[L\ o G K]) = vpContexti(K) 
vpContext(M) = \\ 



where vpContext l '■ VarPropL — ► {Names — Types) is a function for getting a variable 
typing context from local variable properties defined as: 

vpContext L ([Li o L (f var , fch, fqa, ftype)]) = vpC ontext L {Li) * f type 

vpContext £,(□) = [] 



8.2 Progress 

In this subsection, we prove series of progress lemmata, ie. assertions claiming that any 
well-typed configuration which is not terminal can be reduced by some semantic rule. It also 
follows from the proof that the choice of the semantic rule is unique, hence the semantics is 
deterministic. 

Lemma 8.2 (Progress Lemma for probabilism) . If Co = ffl| =1 pj • [gsi \ Isio], q > 1 and 
h Co : r then there exists a configuration C\ such that Cq — > C\. 

Proof. Such a mixed configuration Co is reduced by the rule NP-ProbEvol. □ 

Lemma 8.3 (Progress Lemma for local processes). If Cq = [gso \ (Imsn, vpn, TE tso)] is not 
terminal, TE ^ recv(v), TE ^ send(vi,V2); ; and h Cq : T then there exists a mixed 
configuration C\ such that Co — > C\. 

Proof. By case analysis of all possibilities of the top term stack element TE: 

Case TE = new T(): As Co is well-typed, we know that T is either or channel[T] (from 
the rule T-Alloc). If T = Q^, then the configuration Co is reduced by the rule OP- 
AllocQ. Otherwise T = channel[T] and the configuration Co is reduced by the rule 
OP-AllocC. 

Case TE = I = E: As Co is well typed, we know that types of I and E match (from the 
rule T- Assign). If E = v = ((Zr, lv))j then one of the following rules is applied: 

• OP-AssignNewValue if Iv ^= L and Ir = none, 
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• OP-AssignQValue if lr = (Quantum, q) and aliasSubsy st(I , vpo) is not denned, 

• OP-AssignQAValue if lr = (Quantum, q) and aliasSubsyst(I , vpo) is denned, 

• OP-AssignValue otherwise. 

Otherwise, the configuration Co is reduced by the rule OP-AssignExpr. 

Case TE = 1(E): As Co is well typed, we know that I denotes either a quantum operator or 
a classical method (from the rule T-MethodCall). If E = v then one of the following 
rules is applied: 

• OP-DoMethodCallCl if / represents a classical method, 

• OP-DoMethodCallQ if / represents a quantum operator. 

Otherwise the configuration Co is reduced by the rule OP-MethodCallExpr. 

Case TE = measure^): If E = v then the configuration Co is reduced by the rule OP- 
DoMeasure, otherwise it is reduced by the rule OP-MeasureExpr. 

Case TE = recv(E): As E cannot be v (from assumptions) the configuration Co is reduced 
by the rule OP-RecvExpr. 

Case TE = I: As Co is well typed, we know that varRef(I, vpo) is defined. Configuration 
Co is reduced by the rule OP-Var. 

Case TE = v: If |tso| = 1 then Co is a terminal configuration. Otherwise let UT be the first 
symbol under the top element of the stack. As the configuration is well-typed, we know 
that UT must be a symbol containing a hole. Now: 

Case UT = Ec: Configuration Co is reduced by the rule OP-SubstE. 
Case UT = Sc: Configuration Co is reduced by the rule OP-SubstS. 

Case TE = (E): Configuration Co is reduced by the rule OP-Bracket. 

Case TE = T J;: If TE = T I; then the configuration Co is reduced by the rule OP- 
VarDecl. Otherwise it is reduced by the rule OP-VarDeclMulti. 

Case TE = channel[T] I wit hends [1,1];: Configuration Co is reduced by the rule OP- 
VarDeclChE. 

Case TE = q aliasfor [qo, . . . ,q n ]',: Configuration Co is reduced by the rule OP- 
VarDeclAlF. 

Case TE = ;: Configuration Co is reduced by the rule OP-Skip. 

Case TE = PE;: If PE = v then the configuration Co is reduced by the rule OP- 
PromoForget, otherwise it is reduced by OP-PromoExpr. 

Case TE = o L ; Configuration Co is reduced by the rule OP-BlockEnd. 

Case TE = Be: Configuration Co is reduced by the rule OP-BlockHead. 

Case TE = {B}: Configuration Co is reduced by the rule OP-Block. 

Case TE = if (E) S\ else S2' If E = v, then the configuration is reduced by the rule OP- 
IfTrue (OP-IfFalse) when v is true (false). Otherwise, the configuration Co is 
reduced by the rule OP-IfExpr. 



44 



8.3 Type preservation 



8 TYPE SOUNDNESS 



Case TE = while (E) S: Configuration Co is reduced by the rule OP- While. 

Case TE = o M : Configuration Co is reduced by the rule OP-ReturnVoidImpl. 

Case TE = return;: Configuration Co is reduced by the rule OP- Return Void. 

Case TE = return E;: If E = v then the configuration Co is reduced by the rule OP- 
ReturnValue, otherwise it is reduced by OP-ReturnExpr. 

Case TE = fork m(E);: If E = v then the configuration Co is reduced by the rule OP- 
DoFork. Otherwise it is reduced by the rule OP-ForkExpr. 

Case TE = send(£i,i?2); : If E% 7^ v then the configuration Co is reduced by the rule OP- 
SendExprI. If E 2 7^ v, the configuration Co is reduced by the rule OP-SendExpr2. 
Case Ei = vi and E2 = V2 is prohibited by the assumptions. 

□ 

Lemma 8.4 (Progress Lemma for communication). If Co = [gso \ (Imsn, v Po, recv(v) tso) \\ 
(/msi , vipi , sendfvi ,v?); ts\) \\ ls 2 \\ ■■■ \\ ls n ] : r then there exists a configuration C\ such 
that C — ► Ci. 

Proof. Such a configuration is not terminal because of the elements recv(v) and send(vi,V2); 
on tops of the process term stacks. It is reduced by the rule OP-SendRecv. □ 

Corollary 8.5. It is possible that a process evolves to a stuck configuration. This is the 
case when one process attempts to send/receive a value over a channel end and there is no 
matching process receiving/sending over the corresponding channel end. 

8.3 Type preservation 
8.3.1 Evaluation theorems 

In the definition of LanQ semantics, we assumed that an expression always evaluates to a 
value (or diverges or invokes a runtime error). This assumption was used in all rules which 
manipulate a subexpression Sub of a statement or an expression: The subexpression Sub is 
pushed onto the top of the term stack and the place of the awaited result in the original 
statement/expression is marked with a hole • (see eg. the rule OP-AssignExpr). We expect 
that if the evaluation correctly finishes, the subexpression evaluates to an internal value that 
in the subsequent step replaces the hole. 

However, we have not yet shown that the subexpression evaluation accomplishes this asser- 
tion. We have to prove that the statement /expression awaiting the result of the subexpression 
evaluation is not modified before the evaluation of the subexpression yields an internal value 
(unless a runtime error occurs). 

This will be shown in this subsection. We will use the following semantic predicates on 
configurations: 

• ExpOk which is defined for configurations where the top term stack element of the first 
local process configuration is some expression E, and 

• BFOk and StkRetOk which is defined for configurations where the top term stack 
element of the first local process configuration is some block-forming statements. 
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These predicates satisfiability is determined by the future evolution of the configurations in 
question. 

We will further define inductive syntactic predicates ExpOki, BFOki and show the con- 
nection between these syntactic predicates and the semantic ones. 

The defined predicates are then used in the proof of the statement that if the syntactic 
predicate RetOk defined in Section 5.1 is satisfied for a block- forming statement B then any 
control path of evaluation of B reaches a return; or return E; statement, or a runtime error, 
or diverges (see Lemma 8.15). This proof is later used in proving type preservation lemma 
for — > s (see Lemma 8.21, proof of the case OP-ReturnVoidImpl). 

Definition 8.6. For an expression E, we define a predicate ExpOk(E): ExpOk(E) is sat- 
isfied iff for any configuration Co = [gso\ (lmso,vpo, E tso)] : t, the evaluation of Co either 
diverges or reaches one of the following configurations: 

• [gs n | (lms 0) n, vpo,n, Y tso) II • • • II {lms k>n , vp ktn , ts k<n )], k > 0, or 

• [gs n | (Imso ,n.) t>Po,T7, i RT Err ) || ■ ■ ■ || (I'W'Skm 

Definition 8.7. For a block-forming statement B, we define a predicate BFOk(B): 
BFOk(B) is satisfied iff for any configuration Co = [gso \ (Imso, vpo,B tso)] ■ r, the eval- 
uation either diverges or reaches one of the following configurations: 

• [gs n | (lmso, n ,vpo,n,tso) \\ • • • || (lms k>n , vp kjU , tsk, n )] , k > 0, or 

• [gs n | (lmso n ,vvo, n , return; ts ,„ ts ) || • • • || (lms kjn ,vp k , n ,ts kin )],k > 0, ts , n does not 
contain o~m, or 

• [gs n | (lms 0)n , vpo )n , return v; ts 0) n ts Q ) || ••• || (lms kin ,vp kjn ,ts k:n )],k > 0, ts 0)n does 
not contain o^, or 

• [gs n | (lms .77. i vpo.n ) RTErr ) || • • • || (lms k n , VPk,n,tS kin )},k > 0. 

We further define a predicate StkRetOk(B): StkRetOk(E) is satisfied iff for any config- 
uration Co = [gso | (lmso,vpo, B oj^ ts )] : r, the evaluation either diverges or reaches one of 
the following configurations: 

• [gs n | (lms ,n,vpo,n,Y. ts ) II ••• II (lms kin ,vpk,n,ts k) n)],k>0 l or 

• [gs n | (lms ,Ti.) vPo t n> RT Err ) || ■ ■ ■ || (^^Sfc yj, Vp k ,n,tS k , n )],k > 0. 

Lemma 8.8. Let B be a block-forming statement such that BFOk(B) . Then StkRetOk(B) . 
Proof. The evaluation starts from the following configuration: 

[gso | (lms ,vpo, B om_ ts )\ 
From BFOk(B) we know that evolution of this configuration: 

• Diverges or gets to a configuration: 

[gs n | (lms n , vp n , RTErr ) \\ ■ ■ ■ \\ {lms k)n ,vp k>n ,ts k , n )] 
therefore the lemma holds. 

• Gets to a configuration: 

[gs n > | (lms v /,vp„/, return; ts n > oj^ ts ) || • • • || (lms k y,vp kjn >,ts k;n ,)] 
By application of OP-ReturnVoid, the 0-th process gets to a configuration: 

[gs n t | (lms n >,vp n >, ((none, ±.)) m - ld tsp) \\ ■■■ \\ (lms kin i,vp k>n >,ts kin i)] 
therefore the lemma holds. 
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• Gets to a configuration: 

[gs n i | (lms n t,vp n ', return v; ts n > om. ts ) || • • • || (lms k 

,n' i VPk.n' > 

By application of OP-ReturnValue, the 0-th process gets to a configuration: 

[gs n ' I (lms n ',vp n ', v is ) || ••• || (lmsk,ri ,vpk, n ' ,t$k,ri)] 
therefore the lemma holds. 

□ 

We want to prove that for any expression E the predicate ExpOk(E) is satisfied. We do 
this by defining inductive predicates ExpOki and BFOki with respect to the structure of E 
and B, respectively. The dependency is the following (a <— 6 means a is dependent on 6): 

ExpOko < SFOfco < ExpOkx < < ExpOki < BFOfe, < 

Definition 8.9. Lei .£7 oe an expression, B be a block-forming statement. We define predicates 
ExpOko(E) and BFOk (B) : 

ExpOk$(E) <^=^ E 1 does not contain 1(E) as its subexpression. 
BFOko(B) <=^ B contains only such subexpressions E which satisfy ExpOko(E). 

For any i £ No, we further define predicates ExpOki + \(E) and BFOki + \(B) : 

ExpOki + \(E) <^=^ For any subexpression Eq of E, ExpOki(Eo) is satisfied 

or E = 1(E) and BFOki(M B (I)) is satisfied. 
BFOki+i(B) <^=^ B contains only such subexpressions E which satisfy ExpOki + \(E). 

Lemma 8.10. Let E be an expression such that ExpOk$(E). Then ExpOk(E) is satisfied. 

Proof. By induction on the structure of E. Let Co = [gso \ (lmso,vpo, E_ tso)] : r be any 
configuration. Base case: 

Case E = v: ExpOk(v) trivially. 

Case E = I: By application of OP-Var we reach configuration [gs \ (Ims, vp,v tso)}, hence 
ExpOk(E). 

Case i? = new T(): By application of OP-AllocC/OP-AllocQ reaches configuration 
[gs\ (lms,vp,v tso)], hence ExpOk(E). 

Case E = I = v: By application of OP-AssignNewValue/OP-AssignQAValue/OP- 
AssignQValue/OP-AssignValue we reach configuration [gs \ (Ims, vp,y_ tso)], hence 
ExpOk(E); by application of OP-AssignQAValueBad we reach configuration 
[gs \ (Ims, vp, ISQV )], hence ExpOk(E). 

Case E = recv(v): By application of OP-SendRecv we reach configuration 
[gs | (Ims, vp, v tso)], hence ExpOk(E); by application of OP-RecvUninit we 
reach configuration [gs\ (Ims, vp, UV )|, hence ExpOk(E). 

Case E = measure(v): By subsequent application of rules OP-DoMeasure and NP- 
ProbEvol we reach configuration [gs \ (Ims, vp, v tso)], hence ExpOk(E); by 
application of OP-MeasureUninit we reach configuration [gs \ (Ims, vp, UV )] , 
hence ExpOk(E); by application of OP-MeasureOverlap we reach configuration 
[gs | (Ims, vp, OQV )], hence ExpOk(E). 
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Next we assume that the lemma holds for all subexpressions Eq of E (inductive hypotesis, 
IH). Then: 

Case E = (Eq): By application of OP-Bracket we reach configuration 
[gs | (Ims, vp, Ejx tso)] for which the theorem holds by the inductive hypothesis. 
Hence ExpOk(E). 

Case E = I = Eq: We get the following evolution: 

[qsQ | (ImsQ, wq, I = Eq tap)] ° p - Ab&IGNExpR > [ qgn | (lmsQ,vpn, Eq I = • tsp)] 

IH 

— ► * [gs n i | (lms n i , vp n i , v I = • tsp)} 

OP-SubstE r I / 1 T . m 
► [gs n > | (lms n i , vp n i , I = v ts )\ 

The last configuration is one of the base cases for which the lemma holds. Hence 
ExpOk(E). 

Case E = recv(Ep): We get the following evolution: 

[qsQ \(lmsQ,vpQ, recv(EQ) ts )\ > [qs n \ (lms , vpq, Eq recv( • ) tsQ]\ 

IH 

— >* [gs n i | (lms n t,vp n r,v recv( • ) ts n )] 

OP-SubstE r I / j / \ , \i 
> [gs n < | (lms n t , vp n > , recv( v) ts )\ 

The last configuration is one of the base cases for which the lemma holds. Hence 
ExpOk(E). 

Case E = measure(i^o? • • • >Ee) : We get the following evolution: 
[gs | (Imsp, vpo, measure(E n , . . . ,E P ) ts )] 

OP-MEASUREEXPR r 1/7 n / r-i \ . M 

> [qsQ I (Imsp, vpq, Eq measure) • , . . . ,E P ) tsp)\ 



OP-SubstE 
> 

OP-MeasureExpr 



[gs n i | (lms n ', vp n >, Vq measure( • , . . . ,E P ) ts )] 
[gs n i | (lms n ', vp n t, measur^VQj . . . ,E P ) ts )\ 



OP-SubstE 



[gsn" | (lms n 'i ,vp„." , E P measure(vn, ■ . . , • ) tsp)] 

[gs n m | (lms n »>,vp n »>,Ve measure (v n , ...,•) tsp)] 

[gs n "i I (lms n >r>, v p n ">, measure(vn, . . ■ ,Vp.) tsp)] 

The last configuration is one of the base cases for which the lemma holds. Hence 
ExpOk(E). 

□ 

Lemma 8.11. Let B be a block-forming statement such that BFOkQ(B). Then BFOk(B) 
is satisfied. 

Proof. By induction on the structure of B. Let Cq = [gso | (Imsp, vpo, B tsp)] : r be any 
configuration. Base case: 

Case B = return v;: Si^OA^return v;) trivially. 

Case B = return E;: We get the following evolution: 

[gs a | (lms a , vp a , return E; tsp)] 

OP-ReturnExpr r I / j , m 

> [gsg, |, (lmsa, vpa., E return • ; tsp)\ 

Lemma 8.io > # [g Sn , \ (lms n i , vp n > , RTErr)] ie. the lemma holds 



or [gs-n 1 I [lms n i , vp n i , v return • ; tsp)] 

OP-SUBSTS r 1/7 , , M 

> [gs n < | {lms n i , vp n > , return v; tso)\ 
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In the last step we see that BFOk(B). 
Case B = return;: i?FOA;(return;) trivially. 

Case B = ;: By application of OP-Skip we reach configuration [gs a \ (lms a ,vp a ,tso)], hence 
BFOk(B). 

Case B = v;: By application of OP-PromoForget we reach configuration 
[gs a | (lms a ,vp a ,ts )}, hence BFOk(B). 

Case B = PE;: We get the following evolution: 

[gs a | (lms a , vp a , PE; ts )\ 

OP-Pr.omoExpr r i / , „ „ , Nn 
> [gs a ,\,{lms a ,vp a ,PE_*itso)\ 

Lemma 8.10^ » [gg n , | (lms n i , vp n > , RT Err )] ie. the lemma holds 



or [gs n > | (lms n i , vp n > , v «i ts )) 

OP-SUBSTS r I / 7 , M 

► [gs n > | (lms n >,vp n i, vj is )J 

The last configuration is exactly the previous case for which the lemma holds. 

Case 5 = o L : By application of OP-BlockEnd we reach configuration 
[gs a | (Ims a , vp a ,ts )\, hence BFOk(B). 

Case £>= fork /(vn, ... ,v e );: By application of OP-DoFork we reach configuration 
[gs a | (lms ts ) || (lms 1)a , M. J(v , . . . ,v e )], hence BFOk(B). 

Case B = fork I(Eq, . . . ,E e );: We get the following evolution: 
[gs a | (lmsa, vPa, fork KEn, . . . ,E P ); ts )] 

op-forkExpr > [ qSn< |, (Ims^vpmEo fork J( • E e ); fan)] 

emma s.io^ » [gs„' | (lms n ' , Wn' , RTErr )] ie. the lemma holds 

or [qs„/ | (lms„>,vp n >,vn fork /(•,... ,JS R ); fan)] 
OP-SuBbTS ) [ Q s„, I (/ma„/ , vjo,,/ . fork J(v n , . . . ,E P ); fa n )] 



op-forkExpr > [ q g n/i ^ {Ims^^yy^^E,, fork J(v n , •■-,•); fan)] 
Lemma 8.io > » [qs w // | (Iffly/, vp„" , RTErr )] ie. the lemma holds 
or [gs„«/ | (lms nl „ , up„,„ , fork J(v n , ...,»); fan)] 
OP-SuBbTS ) \g 8n „, | (l m s n »>, vp n >», fork J(v n , . . . ,v ff ); fa )] 
The last configuration is exactly the previous case for which the lemma holds. 

Case B = send(v c ,v„);: By application of OP-SendRecv we reach configuration 
[gs a | (lmso t a, vpo )Cl , tso)], hence BFOk(B); by application of OP-SendUninit we reach 
configuration [gs a \ (lmso :Cl ,vpo ta , UV)], hence BFOk(B). 

Case B = send(E c ,E v );: We get the following evolution: 

[gs a | (lms a , vp ai send( E r ,E„); ts )] 

OP-SendExprI r I / j ^ 77! \ j. m 
> [qSa,\Alms n ,vPa,E r . sendt*,^,); ts )] 

Lemma 8.10^ » [gs n i \ (lms n i , W n ' , RT Err )] ie. the lemma holds 

or [gs n > | (Imv , vp n > , send( • ,E„); ts )] 

OP-SuBbxS ) i y mSn/ ^ vpn/ ^ sen( j( Y „E v ); ts )] 

OP-SendExpr2 r I / 1 7—1 ,/ \ , \ 1 
> lgSn',\AlmSn',vpa>,E v send(v r ., • ); ts )] 

Lemma 8.10^ » [gs n n \ (lms n n , vp n " , RTErr)] ie. the lemma holds 

or [gs n :> I (lms n » , vp n » , sendfv,., • ); ts )] 

OP-SubstS ) j (j ms ^ n ^ vpn// ^ sen d( Vr ,v„); rjs )] 
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The last configuration is exactly the previous case for which the lemma holds. 

Case B = T I;: By possibly multiple application of OP-VarDeclMulti and OP- 
VarDecl W6 reach, configuration [f/Sa | vp a ,tso)], hence BFOk(B). 

Case B = channel[T] I withendsf/,/];: By application of OP-VarDeclChE we reach con- 
figuration [gs a \ (lms a ,vp a ,tso)], hence BFOk(B). 

Case B = I aliasfor [I];: By application of OP-VarDeclAlF we reach configuration 
[gs a | (lms a ,vp a ,ts )], hence BFOk(B). 

Next we assume that the lemma holds for all substatements Ben of B (inductive hypotesis, 
IH). Then: 

Case B = Beo Bei . . . Be m : We get the following evolution: 
[gs a | (lms a , vp a , Be n Bei ... Be m ts )\ 

p-BlockHead ) [ ffSn | (ims^ VVn , Ben Bei . . . Be m tan)] 

IH 

— [gsri I (lms n i , vp n i , RTErr )] ie. the lemma holds 

° r [9 s ri I (lms n i , vp n i , return; Bei ■ ■ ■ Be m tsn)] ie. the lemma holds 

° r [d s ri | (Ifnsni , vp n ' , return v; Bei . . . Be m tsn)] ie. the lemma holds 

or diverges ie. the lemma holds 

or [gs n > | (lms n i , vp n > , Be] . . . Be m tsn)] 

OP-BLOCKHEAD r l/i r, y-j . \ ■] 

► [gs / I [lms a i , vp a , , Be m -i Be m ts )\ 



[ff^n" I (ImSr,", vPr,.», RTErr )] ie. the lemma holds 
or [gs n " | (lmsn" , Wn" , return; Be m tsn)] ie. the lemma holds 
or [gs n n | (lms n ir, vp n ", return v; -Be m tsn)] ie- the lemma holds 
or diverges ie. the lemma holds 
or [gs n » | (Iras n » , vp n " , Be m ts )] 

[ff s n w I (lms„"i, vpn"'i RTErr )] ie. the lemma holds 
or [gs n m | (lms n "i , vp n '"i return; tsn)] ie. the lemma holds 
° r [g s n"' I (lrns n >" ,vp n "> , return v; tsn)] ie. the lemma holds 
or diverges ie. the lemma holds 
or [gs n >i> | (lms n >i> , vp n n, , ts )] 

Therefore the lemma holds for this case. 

Case B = if (v) S± else S2' Depending on v, the evolution continues by rule OP-IfTrue 
to configuration [gs n i \ (lms n / , vp n i , S± tsn)], or by rule OP-IfFalse to configuration 
[g s n' I {lms n i , vp n i , S% tsn)]. By IH, we assume that the lemma holds for both Si and 
52, ie. the lemma holds for this case. 

Case B = if (E) Si else S21 We get the following evolution: 
[gs a I (lms a , vp a , if (E) Si else S?. ts )] 

P-IfExpr > [qg^, I (lmsa, vpg, E if ( • ) Si else S?. ts n )] 
Lemma s.io^ » [gs n > \ (lms n i , vp n i , RTErr)] ie. the lemma holds 

or [gs n < | (lms n > , vp n > , v if ( • ) Sj else S 9 . ts )] 
OP SubstS > [gg n ,/ | (lms n ",vp n ", if (v) 5i else S? tsn)] 
The last configuration is exactly the previous case for which the lemma holds. 
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Case B = { B }: We get the following evolution: 
[gs a | (lms a , vp a , { B } tso)] 

p-Blook > [gs a \(lms a ,vpa',Boi L tsQ)] 

~~ > * [gsn.i I (Imsn'f vpn/i RTErr) ] ie. the lemma holds 

or [g s n' I (lms n i , vp n i , return; ts n > oj^ tso)] ie. the lemma holds 

or [9 s ri I (Imsr,/ , vp n ' , return v; ts n / iso)] ie. the lemma holds 

or diverges ie. the lemma holds 

or [gs n < | (lms n < , vp n < , ts )) 

OP-BLOCKEND r I / 7 , M 

► [gs n > | (lms n >,vp a , ts )\ 

Therefore the lemma holds for this case. 

Case B = while (E) S: We get the following evolution: 
[gs a | (lms a , vp a , while (E) S ts )] 

P " WHILE > [gs a | (lms a , vp a , if (E) {S while (E) S} else ; ts )] 
see if case ^ ^ [qg^, | (lms n i , vp n > , RT Err )] ie. the lemma holds 
or diverges ie. the lemma holds 

or [g s n' I {lms n i , vp n i , if (v) {5 1 while 5} else ; tsn)] 
Depending on v, the evaluation continues either this way: 

OP-IfFalse r , \ i 
► [gs n / | (Imv , vp n i , i ts )J 

0P " SKIP> [gs n > I (Zms n / , ujv , ts )] 
so the lemma holds for this case; or the evaluation continues as follows: 
OP-IfTrue 



[gs n 

OP-Block r 

► [gs n 

OP-BlockHead r 

> [gs n 

— ► * [gs n 



{lms n i , vp n ' , {S while (E) S} tso)] 

(lms n i , vp n i , S while (E) S qj, tso)] 

(lms n i , vp n i , S_ while (E) S qj, tso)] 

(Imsn" i vPn." i RTErr) ] ie. the lemma holds 
(lms„." , vp n " i return; is n " ^ s o)] the lemma holds 
(lms n n , vp n " , return v; ts n " ts$)] ie. the lemma holds 



or [gs n » 

or [gs n n 

or diverges ie. the lemma holds 

or [gs n " | (lms n ii, vp n ", while (E 1 ) 5 qj, tso)] 

Therefore it is possible that evaluation of while statement continues forever. This is 
the statement of the lemma, hence the lemma holds even for this case. 

□ 

Lemma 8.12. Let E be an expression such that ExpOki + \{E). Then ExpOk(E) is satisfied. 
Proof. The proof proceeds similarly to the proof of Lemma 8.10. We must only add two cases: 

Case E = /(v): We know that the predicate BFOki{Mfj{I)) is satisfied, hence by Lemmata 
8.13 for BFOh and 8.8, the predicate StkRetOk(M B (I)) is satisfied (f). We get the 
following evolution: 

[gs a | (lms a , Vp a , i"(v) tS a ] 

OP-DoMethodCallCl r , . , , TN . \i 

* [gs n ' I [lms n > , vp n i , Mn(I) oj^ ts ) ] 

^h* [gs vfl | (lms v n , vPp/> , RTErr ) || • • • || {lms k>n n,vp k , n n,ts k>n n)] 

or [gs n » | (lms , n ", vpo,n",Y ts o) II • • • II {lms k , n >>, vp k , n ", ts k , n ")] 
or diverges 

Therefore the lemma holds, ExpOk(E). 
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Case E = I(Eq, . . . ,E e ): By induction on the structure of E: Assume that the lemma holds 
for all Eq, . . . , E e (inductive hypotesis, IH). We get the following evolution: 

[gs | (lms , vp , I(E n , . . . ,E P ) ts )] 
OP-MethodCallExpr 



OP-SubstE 
> 

OP-MethodCallExpr 



[gs | (lms , vpo, E& /(»,... ,E P ) ts )} 

[gs n > | (lms n >,vp n ',Yn !(• E P ) ts )] 

[gs n > | {lms rt >,vp n > J(vo E P ) ts )] 



OP-SubstE 



[gs n » | (lms n »,vp n >i,Ej, J(v n , ■ ■■,•) ts )} 

[gs n m I (lmSr,.Hi,Vp n »',Ve. Hyo, ■■■■,•) ts )] 

[gs n m I (lms n >»,vp n i», Kvq, . . . ,v e ) ts )] 

The last configuration is one of the base cases for which the lemma holds. Hence 
ExpOk(E). 

□ 

Lemma 8.13. Let B be a block-forming statement such that BFOki + \{B). Then BFOk(B) 
is satisfied. 

Proof. The proof is nearly identical to the proof of Lemma 8.11. We only exchange all usages 
of Lemma 8.10 for evaluation of expression E by Lemma 8.12 for ExpOki(E). □ 

Corollary 8.14. For any at most countably derivable expression E, ExpOk(E) is satisfied. 
For any at most countably derivable block-forming statement B, BFOk(B) is satisfied. 

Informally, as the programs are always countably derivable, we have proved the following: 

• Unless a runtime error occurs, the evaluation of an expression E never modifies term 
stack elements under the evaluated expression. If the evaluation does not diverge, the 
expression E always yields an internal value, 

• Unless a runtime error occurs, the evaluation of a block-forming statement B never 
modifies term stack elements under the evaluated statement if it does not get to a 
return statement. In that case, it pops all the elements from the term stack up to the 
first occurence of the symbol o M . 

Lemma 8.15. Let B be a block-forming statement such that RetOk(B). For any configuration 
Co = [§ s o I (Imso, vpo, B tso)] : t, the evaluation either diverges or reaches one of the following 
configurations: 

• [gs n | (lms , n ,vpo in , return; ts ,„ ts ) || • • • || (lmsk, n , vpk,n, ts k ,n)}, k > 0, is , n does not 
contain om, or 

• [gs n | (lms() n , vpo in , return v; ts 0) n ts Q ) \\ • • • || (lms kin ,vp ktn ,ts k:n )],k > 0, ts 0)n does 
not contain o^j, or 

.77. i vpr\ t n i RTErr ) || • • • || (lms ktn , Vp k ,n,tS kin )},k > 0. 

Proof. By induction on the structure of B. Let Co = [gso \ (Imso, vpo, B tso)] ■ r be any 
configuration. Base case: 

Case B = return v;: The lemma holds trivially. 
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Case B = return Ey. We get the following evolution: 

[gs a | (lms a , vp a , return E\ ts )] 

OP-ReturnExpr r I / j , m 

► [gsg, |, (lmsa, vpg, E return • ; ts n )\ 

— P ° ' ~> * [qs-n/ | (lms n i,vp n ', RTErr )] ie. the lemma holds 
or diverges ie. the lemma holds 
or [9 s ri I {lms n >, vp n >, v return • ; iso)] 

OP-SUBSTS r I /i . M 

► [9 s n' I {lms„i, vpn'i return v; ran )J 

In the last step we see we get requested configuration, hence the lemma holds. 

Case B = return;: The lemma holds trivially. 

Next we assume that the lemma holds for all substatements Be of B such that RetOk(Be) 
(inductive hypotesis, IH). Then: 

Case B = Beo Be\ . . . Be m : We know that there is at least one j such that RetOk(Bej). 
Let b be smallest such j. Moreover, BFOk(Bei) for < i < m. We get the following 
evolution: 

[gs a | (lmSg,vpa, Beo Be] ... Be m ts n )] 

p-BlockHea D> ^ | (i mSai vpa: Be] ... Be m ts )] 

BFOk(Beo) 4 _ 

► [gsri I \lfns n i , vp n i , RTErr )\ ie. the lemma holds 

or [9 s ri | (lms n i , vpn' , return; Be] . . . Be m tso)] ie. the lemma holds 

or [9 s ri I (lms„.i, vPn>, return v; i?ei . . . Be m tso)] ie. the lemma holds 

or diverges ie. the lemma holds 

or [gs n > | (lms n > , up n < , Be] ... Be m ts Q )] 

OP-BlockHead r I / T „ . , m 
► [gs a > I {lms a i,vpa>,Bebts ,a> ts )\ 

By IH, the lemma holds for the last configuration, therefore it holds for this case. 

Case B = if (v) Si else S2' Depending on v, the evolution continues by rule OP-IfTrue 
to configuration [gs n i \ (lms n i , vp n > , S± tso)], or by rule OP-IfFalse to configuration 
[gsri I (lms n i , vp n i , S% tso)]. From definition of RetOk, both RetOk(Si) and RetOk(S2) 
are satisfied. By IH, the lemma holds for this case. 

Case B = if (E) Si else S21 We get the following evolution: 
[gs a I (lms a , vp a , if (E) S] else S?. ts )] 

op-IfExp R) ^ j j^ m8 ^ vp ^ £ if ( » ) ^ else S?, tso)] 

— P ° ' ' > * [g s ri I (lrns n ' ,vp n i , RTErr)] ie. the lemma holds 

or diverges ie. the lemma holds 

or [gs n > I (lms n > , v p n > , v if ( • ) S] else ts )] 
OP-SubstS ) 1 ^ ms ^ ; ^ ^ ^ if ( v ) gj else ^ is )] 

The last configuration is exactly the previous case for which the lemma holds. 

Case B = { B }: We get the following evolution: 

[gs a I (lms a ,vp a , { B } ts )] ° P " Bl ° ck > [£s a | (Zms a , vp a >,B ts )] 
By IH, the lemma holds for the last configuration, therefore it holds for this case. 

□ 
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Informally, for any block- forming statement B such that RetOk(B), we have proved the 
following: 

• Unless a runtime error occurs, the evaluation of B always leads to a return statement 
or diverges. 

8.3.2 Type preservation lemmata 

In the previous subsections, we have proved that for any well-typed configuration Co : r, there 
exists a configuration C\ such that Co — ► C\. The next step in proving type soundness is 
to prove that any such one-step evaluation preserves the type of the configuration. In other 
words, that the configuration C\ is well-typed, C\ : r', and that r' = r in the case of single 
process-evolution or r' = r x 6 in the case of the fork statement. In all cases, the type of the 
original processes is preserved. 

Lemma 8.16 (Type preservation for — > v ). Let Co = [gsn \ (Imsn, Wo, TE tso)], C\ = 
EBf =1 Pi • Ci t i where = [gsjj \ (Imsjj ,vpjj , TEj is^i)] be two configurations such that 
Co — > v C\. If Co : t then C^i : r for all i. 

Proof. From Co : r we know: 

(1) (2) 
T-rule 



M; vpContext(vpo) hx TE : r' * M; he {Itusq, vpo, tso) : t' — * r 

— a — T TC-ExprClo 

M;0 h c (lms ,vp ,T\E ts ) : void — > r 

T-Config 



M; h [gs \ (lms , vp ,TM ts )] : t 
For each i = 1, . . . , n, we want to prove C^i : r: 

(premise(T-rule)) (3) 

T-rule 



M; vpContext(vpi i) T£"i : r' M; \~c (Imsi i,vpi i,tsn) : t' — > r 

— 7 \ rj— ' ■ TC-ExprClo 

M; he (tmsj i , vpi i , i rsi i J : void — » r 

T-Config 



M;0 h [gsf.i | (lmsiA,vp it u TEi ts^i)] : t 

As — rules change the top stack element only, tso = tsu for all i, therefore we must 
only prove TE : r' ^> TE{ : r'. We do this by case examination of relation — 

OP-AllocC: TE : channel[T] from T- Alloc. TE { = ((R, v)) channe |[ T]) thus TE { : channel[T] 
from T- Value. 

OP-AllocQ: TE : Q d from T- Alloc. TEi = ((i?,v)) Qd , thus TEi : Q d from T- Value. 

OP-AssignNewValue, OP-AssignQAValue, OP- AssignQ Value, OP- Assign Value: 

TE : T from T- Assign. TE { = ({fl,v)) T , thus : T from T- Value. 

OP-DoMeasure: TE : int from T-Measurement. TE { = ((none, Vj)) int , thus TE { : int 
from T- Value. 

OP-DoMethodCallQ: As all methods representing quantum operators are regarded as 
method with return type void, TE : void from T-MethodCall. TEi = ((none, -L)) V oid, 
thus TEi ■ void from T- Value. 

OP-Var: TE = x : T from T-Var, hence vpContext{vpo){x) = T. TEi = 
((R,Vx))typeOf(x,vp itl ), tnus TE i '■ typeOf(x,vp it i) from T- Value. We know that 
vpo = vpn as rule OP-Var does not modify variable properties. From definition 
of vpContext, typeOf(x, vp^i) = T vpContext{vpi i \){x) = T. 

□ 
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Lemma 8.17 (Type preservation for — > e ). Let Co = [gsn | (Iwsn, vpn, TEn tso)], C\ 
[gsi | (Imsi, vpi, tsi)] be two configurations such that Co — > e C\. If Co : r then C\ : r. 

Proof. We prove this lemma for each rule of relation — > e : 
OP-MethodCallExpr TE = m(y,E,E). From C : r we know: 

(5) 

(4) M; h c (Zms , vp , ts ) : r' -► r 

TC-ExprClo 



M; he (Imso, vpn, m(v,E,E) ts ) : void — > r 

3 ~ T-Config 

M; h [gs I (lmsn,wn, m(v,E,E) ts )] : r 

where (4) is: 

(7) 

(6) M;vpContext{vp )^ T E:a % 

T-MethodCall 



M;vpContext(vp ) hy m(v,i?,_B) : r' 
We want to prove Ci : r: 

(?) 

M; vpContext(vp ) Y- T E : o (10) 

= TC-ExprClo 

M; hp (Imso, vpo,E m(v, • tso) : void — > r 

= T-Config 

M; h [gs Q \ (lms , vp ,E m(v, • ,£') is )] : T 

where (10) is (here we denote vpc = vpContext(vpo)): 



(11) M-vpc,* : ah T • ■ a (12) ( 13 ) 

M; vpc, • : a h T m(v, • : r' M; h c (lms , vpo, ts ) : t' — » t 

M; h c (lms , vp , m(v, • ts ) o —> t 
Realizing that (9) = (7), (11) = (6), (12) = (8), and (13) = (5) finishes the proof. 



TC-ExprHole 



OP-AssignExpr, OP-IfExpr, OP-MeasureExpr, OP-PromoExpr, OP-RecvExpr, 
OP-SendExprl, OP-SendExpr2 The proof is a straightforward alteration of the proof of 
OP-MethodCallExpr. 

OP-ForkExpr TEq = fork m(v ,E ,E);. From Co : r we know: 

(15) 

(14) M; h c (lms , vp , ts ) : void -> r 

TC-StatClo 



M; he {Imso, vpn, {ork m(v,E,E); ts ) : void — > t 

~ T-CONFIG 

M ; h [gso | (Imso, fjPn, fork m(y,E,E); ts )} : t 
where (14) is (here we denote vpc = vpContext(vpo)): 

(17) 

(16) M-vpcV T E:a (18) 

= T-MethodCall 

M; vpc hy m(v,E,E); : t' m is a classical method 

~ T-Fork 

M; vpc \~t fork m(v,E,E); : void 
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We want to prove C\ : r: 

(19) 



Af ; vpContext(vp ) h T £ : a (20) 

TC-ExprClo 



M; he (Imso, vpo,E fork m(v, • ,E); top) : void — > r 

~ T-Config 

Af; h [gso \ (lmso,vpo,E fork m(v, • ,E); top)] : r 



where (20) is (here we denote vpc = vpContext(vpo)): 



(21) M; vpc, • : u hy • : <r (22) 

M; ape, • : cr h T ro(v, • ,E); : t' (23) 



M; vpc, • : cr h^ fork to(v, • ,f?); : void Af ; he (Zmsp, vpo, too) '■ void — > r 

~ TC-StatHole 

Af; hp (Imsg, vpp, fork m(v, • ,£'); top) : cr — > r 

Realizing that (19) = (17), (22) = (18), (21) = (16), and (23) = (15) finishes the proof. 

OP-ReturnExpr TEq = return E;. We know that vpo = vpi = [vpc °g v p]i tso = 
. . . Qiu ts r . Denote by p = typeOf(@retVal, vp\). From Co : r we know: 

(24) (25) 



Af ; vpContext(vpo) hy E : p M; he {Imsp, vpc, ts r ) : p — > r 

r - ^ , r TC-RETEXPR 

Ai ; he (imso, vpo, return E\ . . . q-m ts r ) '■ void — > t 

T-CONFIG 

M; h [c/s | {lms , vpp, return jg; . . . to r )] : t 
We want to prove C\ : r: 

(26) 



M; vpContext(vp ) h T E : p (27) 

TC-ExprClo 



Af; he (Imso, vp ,E return • ; . . . ojvl ts r ) : void — > r 

T-CONFIG 

M; h [gso | (Imso, vpo,E return • ; . . . oj^ ts r )] : r 
where (27) is: 

(28) 



M; he (lms , vp G , ts r ) : p 



TC-RetHole 



Af ; he (Imso, vpp, return • ; . . . qm to r ) : void — * r 
Realizing that (26) = (24), and (28) = (25) finishes the proof. 
OP-DoMethodCallCl TE = m(v). From C : r we know: 

(30) 

(29) Af ; he (?ms , vp , top) : t' -> t 
Af ; he (lms , t>p , m(v n , ■ ■ ■ ,v ra ) top) : void -> r CoNFIG 
Af ; h [gsp | (lms , vvn. mivn, . . . ,v n ) ts )} : r 

where (29) is inferred by rule T-MethodCall: 

(32) 

Af ; vpContext(vpo) hy Mr(m) = crp, . . . , <r n — * t' (31) 



TC-ExprClo 



Af ; vpC ontext(vp ) hy v : (Jo 
Af ; vpContext(vpo) hy Jn(vp, . . . ,v„) : t' 
We want to prove C\ : r: 
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(33) 

T-Block 



M; vpContext([vp o G [□ o L vp' M ]]) \~t Ms(m) : void ~ "' (34) 
M; l- c (Zms , [vp o G [□ o L up' M ]], M B (m) , o M| tso) : void -> t 

T-CONFIG 

M; h [^so I (ims , [«Po °g [□ °l ^Pj f ]], M B (m) o M fso)] : t 
where M = (M T ,M H ,M B ) and (34) is: 

(35) 

M; h c (Zms , i>Po, *s ) : typeOf(@retVal, [vp o G [□ o L up^-]]) -> r 

„ ; p. j-y. — TC-RETlMPL 

Method body is always a block. This justifies usage of rule T-Block. To see that the 
premises (35) and (30) specify the same proof, we recall the premise (31): the return 
type of method m is r'. From the definition of rule OP-DoMethodCallCl we get 
that typeOf(@retVal, [vpo oq [□ o L vp' M ]]) = t' . This finishes the proof. 

OP-SubstE TEq = v, moreover the symbol under the top element is Ec. From Co : r we 
know: 



M;0h T «r,v)) T :T(36) T " Value (37) 



M; he (lms ,vpo,v Ec ts ) : void 



M; h [gs a \ (lms , vp ,v Ec ts )] : 
where (37) is: 

(38) (39) 



TC-ExprClo 

T 

— T-CONFIG 



M; vpContext(vp ),u : T hy Ec : r' -M; he (Imso, vpo, tso) : r' — > r 

— -r- TC-EXPRHOLE 

M; he {tmso, vpo,Ec tso) : T — » r 
We want to prove Ci : r: 

(40) (41) 



M; vpContext(vpo) h^ -Bc[v] : t' M; he (lmso,vpo,tsQ) : t' — ► r 

rrin 71 n r i , — s n TC-ExprClo 

M; he (Imso, vpo, hc\v\ ts ) : void — * r 

T-Config 



M ; h [gs I (Zms , ^jP n , -Ec[v] fs n )] : r 



From the premise (36), we know v : T. The substitution of v in place of • is just an 
a-conversion that does not change type (• : T). Indeed, (41) = (39), and (40) = (38) 
what finishes the proof. 

OP-SubstS The proof is a straightforward alteration of the proof of OP-SubstE. 

□ 

Lemma 8.18 (Type preservation for OP-DoFork). Let Co = 

[gs n I (Imsn, Wo, fork m(v); ts n )] , Ci = [gsi\ (lmsi,i,vp lil ,ts 1)1 ) || (Zmsi, 2 , vp 1>2 , ^1,2)] 
6e too configurations such that Cq op DoFoRK > p c^. If Co : t then C± : t x 6 . 

Proof. From Co : t we know: 
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(42) 

T-MethodCall 



M;0h T m(v):T (43) 

T-FORK 



M ; \~t fork rn(v); : void M; he (Imso, vpo, tsg) : void — > t 

M;0 \~n (Imso.vpn. iork to(v); £sq) : void — > r 

T-Config 



Af;0 h [gs n | (/ms ,t>p , fork m(v); is )] : r 
We want to prove C\ : t x 0: 

(44) 

M; he (/msi^i, wpo, ^ s o) : void — » t (45) 

T-CONFIG 

M; h [gs | (Zmsi,i, vp ,ts ) || (Zmsi >2 , upi, 2 > *si,2)] : r x 6< 
where (45) is: 

(46) 

T-MethodCall TC-Empty 



M;0h T m(v'):T M; h c (im«i a , ■, e) : T • 

- ■ TC-ExprClo 

M;0 h c (lmst 7 2,M, m(v') ) : void -> 6> 

By inspecting the definition of rule OP-DoFork we see that transformation from v to 
v' preserves typing of individual values. Hence (46) = (42) and 6 = T. Realizing that (44) = 
(43) finishes the proof. 

□ 

Lemma 8.19 (Type preservation for OP-SendRecv). Let Co = 
[qsp | (/ms n ,i , vpo,i , send(v. s ,v„); is ,i) || (Imsnp, vpnp., recv(v r ) ts 0t2 )}, C\ = 

[gs± | (Zmsx,i, fPi,i, jj (Imsip, vpip, tsxp)) be two configurations such that 

„ OP-SendRecv n r(/1 „ „ „ 

Co > p 6\. Ij Co : t x 6 then C\ : r x 0. 

Proof. From Co : r x 6 by rule T-Config we know: 

(48) 



(47) M; he (^ms lj^po i,*so l) : void — » t 

77 ^ r — 71 T? w \ n TC-StatClo 

iW;0 h c (/msn,i , wpry , send(v. 8l v„ ); ts ,i) : void — > r 

where (47) is (here we denote fpco.i = vpContext(vpo,i))'- 

T- Value — , T- Value 



M; vpco 1 hy v s : channelEnd[r v ] M; vpco 1 h^ v„ : t v 

— : r — T-Send 

M;vpco,i \~t send(v s , v v ); : void 

and (here we denote vpc^^ = vpContext^po^))'- 

T- Value 



M;vpc 02 h T v r : channelEnd[0'] " • • ■ / 4g \ 

T-Recv 



M; vpc , 2 h T recv(v r ) : 9' ~ M; h c (lms 0l i,vpo l2 ,tso, 2 ) ■ 9' —> 9 

a — r- . - TC-ExprClo 

M;0 h c {Imspfl, «Po,2, recvXy c j ts , 2 ) : void -> 

We want to prove Ci : r x 0: 

(50) 



M;0 h c (Imsi i, t>Po,i>* s o,i) : v0 'd — * r (51) 

T-CONFIG 

h [gs I (/msi^^^i^so,!) || (ims lj2 , ^1,2, fs 1)2 )] : r x 
where (51) is (here we denote vpc\^ = vpContext{vp\p)\. 

(52) 

T- Value 



M;vpc lt 2 hr : 9" M;0 h c (Zmsi 2 , ^0,2,^0,2) : 0" 

: fl . - TC-ExprClo 

M; he (tmsi,2,vpo,2) Yu iso, 2 ) : void — > & 
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By inspecting the definition of rule OP-SendRecv we see that v s and v r are ends of the 
same channel, hence their types match. Therefore, 6' = r v . Indeed, 6" = r v . As changes in 
local memory state does not change type, (52) = (49). Realizing that (50) = (48) finishes the 
proof. 

□ 

Lemma 8.20 (Type preservation for — > r ). Let Co = [gsp \ (Imso, vpp, TEq tso)], C\ = 
[gs± | (lmsx,vpi,tsi)] be two configurations such that Co — v Ci- If Co : t then C\ : r. 

Proof. We prove this lemma for each rule of relation — > r : 

OP-BlockHead TE = B~e = Be Bet . . . Be n , n > 1. From C : r we know: 



(53) 

M; he (lmsn,vvo, Beg Be-\ . . . Be„. tso) : void — > r 



M; \- c (Imso, vp ,Be ts ) : void — > r 

= T-Config 

M; h [gs \ (lms , vp ,Be ts )] ■ t 



TC-BlockHead 



We want to prove C\ : r: 



(54) 

M; \~c {Iwisq, vpn, Ben Be\ . . . Be r , tso) : void — > r 
M; h [<?sq | (Imso, vpo, Ben Bei . . . Be n tso)} : r 



T-Config 



Indeed, (53) = (54). 

OP-Bracket TE = (E). From C : r we know: 
(55) 

M ; vpContext(vp ) \- T E : t' (56) 

T- Bracket 



M;vpContext(vpo) hy : t' M; \~c (lmso,vpo,tso) : t' — > r 

^ — t, - TC-ExprClo 

M ; hp (imso, vp , (E) ts ) ■ void — > r 

M; h [gs I (ims , wp , M too)] : r T " CoNFIG 

We want to prove C\ : r: 

(57) (58) 



M;vpContext(vpo) h^ -E : t' M; he (lmso,vpo,tsn) '■ t' — > r 

. — — - TC-ExprClo 

M; h c (lms , vp 0} E ts ) : void — > r 

— — rt , — r , — — T-CONFIG 

M;0 h [gs | (lms ,vpo,E ts )\ ■ r 

Indeed, (57) = (55), and (58) = (56). 
OP-VarDeclMulti TE = T I ,h, . . . ,I n j- From C : r we know: 



(59) 

M; h c (imso, ^Po, TJoi T h,... ,/„,; ts ) : void ->■ r 



M;0 h c (Imsp, vp ,T h,h, ■ ■ ■ J^j ts ) : void -> r ? _ ^ 
M; h [gs n ] ffrnsn, uPn, T JnJi , ■ ■ ■ ,J»; ton)] : r 



TC-VarDeclMulti 



We want to prove C\ : r: 
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(60) 



M ; h c (Imso, vp n , T h; T h , . . . J n ; ts Q ) : void -> r 

T-CONFIG 



I" [.9 s o I (lms , vp , T J n ; T h, . . . ts )] : r 

Indeed, (60) = (59). 
OP- While TE Q = while (E) S. From C : r we know: 

(62) 



(61) M; h c (Zros , vp , ts ) : void -> r StatClc 
M;0 he (lmso,vpo, while (E) 5 tso) : void — > r 
M; h [gs \ (Imsc vpp, while (E 1 ) 5* ts )] : t 

where (61) is (here we denote vpc = vpContext{vpo))'- 

(63) (64) 



M; vpc hy E : bool M; vpc h^ S : void 

— : —. — ^ n T- While 

M; vpc \~t while (E) S : void 



We want to prove C\ : r: 



(66) 

(65) M; h c (Zms , vp , ts ) 



TC-StatClo 



M;0 h c (lms ,vpo, if (E) {S while (E) S} else ; tap) : void -> r 
M;0 h [qs n | (Zman.Wn, if {5 while (E) S} else ; top)] : r 

where (65) is (here we denote vpc = vpContext{vpo))'- 

(67) (68) 



T-Skip 



M; vpc hy _E : bool M; vpc hy {5 while (E) S} : void M; vpc hy ; : void 

M; vpc h T if (E) {S while (£) 5} else ; : void T_lF 

where (68) is by T-Block (here we again denote vpc = vpC ontext{vpo)): 

(70) (71) 

(69) M; vpc h T E : bool M: vpc h T 5 : void 

T- While 



M; vpc \~t S : void while (E) S : void 

— — - — — — - T-BlockHead 

M; vpc h T 5 while (E) 5 : void 

Indeed, (67) = (70) = (63), (69) = (71) = (64), and (66) = (62). 



□ 



Lemma 8.21 (Type preservation for — > s ). Let Co = [qsn \ (Imso, vpn, TEn tso)], C\ = 
[gs\ | (lmsi,vpi,tsi)] be two configurations such that Co — > s C\. If Co : r then C\ : r. 

Proof. We prove this lemma for each rule of relation — > s : 

OP-Block TEo = {-B}. From Co ■ r we know (here we denote vpc = vpC ontext{[vpQ oq 
vp])): 
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(72) 

M: vpc \~t B : void (73) 

X-Block 

M; vpc \~t {£?} : void ' M; he (Imso, [vpc °g vp], * s o) : v °id — > t 

Af; he (Imso, [vp G o G vp],{J3^ tso) : void — ► t 

T-Config 



M; h [gs | (Zmso, [vp G o G vy],{B} ts )] : r 
We want to prove C\ : r: 

(74) 

M; vpContext([vpG °g [vp°L □]]) hy -B : void (75) 
M;0 h c (Zms , [upc °G ^P°l Q]],B2l is o) : void -> r 

I -( ONFTP 

M;0 h [gs I (lms , [uPg °g [«P°l *s )] : r 

where (75) is: 

(76) 



M;Q \- c (lms ,[vp G o G vp],ta ) '.voider ^ 

, , ^ , z. , r ==p; , — s TC-BlockEnd 

M; h c (Imso, [vpc °G [vp °l QJJ,2l ts ) : void -> r 

Indeed, vpC ontext([vpG °g [ v P °l D]]) = vpContext([vpG °g vp}), hence the premises 
(74) and (72) are the same. Realizing that (76) = (73) finishes the proof. 

OP-BlockEnd TE = o L . From Co : r we know: 

(77) 



M; h c (^tos , [up G °G «jJ ,*s ) : void ->■ r 

, , rt , j-, , , , — v n TC-BlockEnd 

M; h c (<ms , [vp G o G [vp o L vpL\\,2i*ts ) : void -> r CoNplG 

M;0 h [gso | (Zms , [vpc °g [«P°l "Pi]], Sl. <«q)] : t 
We want to prove Ci : r: 

(78) 



M; h c {ImsQ, [vp G o G vp],ts ) : void — > t 

— T-CONFIG 



M;0 h [gs \ (lms , [vp G o G vp],ts )] : • 
Indeed, (78) = (77). 
OP-IfFalse TE = if (((r, false}} boo l) Si else S 2 . From C : r we know: 

(80) 

(79) M; h c (?ms , vp , tsg) : void -> r StatClc 

M; h c (Zms , pp , if ( ((r, false)) hnn i ) Sj else 5? ts ) : void -> r 

I -( ONPTC 

M;0 h [qs n | (Zms n ,t>iOn, if (((r, false)) h nni) g] else ff? ts )] : t 
where (79) is (here we denote vpc = vpContext(vpo)): 

(81) (82) (83) 



M; vpc hx ({r, false)) bool : bool M; vpc hy Si : void M; vpc hr S2 ■ void 

T-If 

M;vpc hx if (((r, false)) bool) Si e l se 5*2 : void 

We want to prove C\ : r: 
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(84) (85) 

M; vpContext(vpo) \~t S% ■ void M; \~c (lms , vpo, tso) : void — > r 
M; \~c (Imso, vpo,S2, tso) : void — > r 

T-CONFIG 



TC-StatClo 



M; h [ss I (lms , vp ,Sz ts )] : r 
Realizing that (84) = (83), and (85) = (80) finishes the proof. 
OP-IfTrue The proof is a straightforward alteration of the proof of OP-IfFalse. 
OP-PromoForget TEq = v;. From Co : r we know: 

(86) (87) 



M;vpContext(vpo) hy v; : void M; \~c (lmso,vpo,tso) : void 
M; h c (lms , vp ,Yl ts ) : void -> r 

T-Config 



— TC-StatClo 



M; h [gs I (Zms , wp , Y| £s )] : r 
We want to prove C\ : r: 



M; \~c (Imso, vpo,tso) : void — > r 

r 



T-CONFIG 



M; h [#s I (Zms , "Po, *So)] 
Realizing that (88) = (87) finishes the proof. 
OP-ReturnVoidlmpl TEq = o M . From Co : r we know: 

(89) 

M;0 h c (lms ,vp G ,ts ) : typeOf(@retVal, [vp G o G vp}) -> r 

, r ^ . -7- r , , — v -, TC-RetImpl 

M; h c (Zms , «Pg °g wpj, m is ) : void r 

T-CONFIG 



M; h [gs I (^rnso, [«Pg °g oj^ ts )] : r 
We want to prove C\ : r: 



(90) 



M;vpContext(vpG) I~t ((none, _L)) V oid : void M;0 he* (lmso,vpG,tso) '■ void — ► r 

r -r , -. j. ~r. ; — r TC-EXPRCLO 

M; h c {lms , vpc ((none, -L)) vn id ts ) : void — > r 

T-CONFIG 



M;0 h [ffso I {lms ,vp G , ((none^-L^niri ts )] : r 
We must prove that typeOf(@retVal, [vpc °g vp}) = void. 

The only way to get o M to the stack is by invoking method m using rule OP- 
DoMethodCallCl which also sets typeOf(@retVal, [vpo °g v p\) to the return type 
T of the method m. The method is well-typed. 

Let T be not void. From the premises of typing rule T- Method, this means that 
RetOk{M 's(m)) is satisfied. However, by Lemma 8.15 we know that there must be 
a return; or return v; statement evaluated during evaluation of method m's body. 
This would replace o M . But this contradicts our assumption that TE = o M . Therefore 
typeOf(@retVal, [vpc °g vp}) = void. 

The proof of this case is now finished as (90) is equal to 
OP-Skip TEq = ;. From Co : r we know: 



(91) 

T-Skip — 

M; vpContext(vpo) hy ; : void M; he (Imso, vpo, tso) : void — > r 

- ^ - . — TC-StatClo 

M; h c {Imso, vp 0: i ts ) : void — > r 

M; h [#s I (Zms , vpo, i *so)] : ^ 
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We want to prove C\ : r: 

(92) 



M;0 l- c (lms ,vp ,ts ) : void ->■ r 

, - rt . — r T7^ , ^ T-CONFIG 

M; h [gs | (lms , vp , ts j\ : r 



Realizing that (92) = (91) finishes the proof. 
OP-VarDecl T£o = T x;. From Co : r we know: 

(93) 

M; h c (Zms , [w??g °g vp' L ]],ts ) : void -> t 



TC-VarDeclOne 



M;0 h c (Zms , [^Pg °g «p /-,]], T x; is ) : void — > t 

T-CONFIG 

M\$h[gso\(lrns ,[vp G o G [vpo L vp L ]],Tjcitso)]:T 
We want to prove C\ : r: 

m 

M; h c (lms , [vp G o G [vpo L vp'{]],ts ) : void -> r 



M; h [#s | (^tos , Ng °g [vp °l vj/[\], ts )] : r 



T-Config 



where vp" L = vp L [x i-> none] +i „ ar .[2; h-> T] +:t2/pe . 

By definition, V L = (fLrJ'ch' f'qaJtype) and Vl = ifvarJch'fqaJtype)- F™ defini- 
tions of OP-VarDecl and TC-VarDeclOne, we get f type = f" ype . This is enough to 
see that (94) is equal to (93) as the other parts of the variable properties tuples (ie. 

fvan fch> fq<V fvnn f"h' fqa) are never used in tyP in g- 

OP-VarDeclAlF, OP-VarDeclChE The proof is a straightforward alteration of the proof 
of OP-VarDecl. 

□ 

Lemma 8.22 (Type preservation for — >ret)- Let Co = [gso \ (Imso, [vpc °g 
vp],TEq ■■■°M.tso)], C\ = \gs\ | (Imsi, vpa, tsi)] be two configurations such that Co — > r et 
Ci. If Cq : t then C x : r. 

Proof. We prove this lemma for each rule of relation — > re j: 

OP-Return Value TEq = return v;. From Co : r we know (here we denote vpc = 
vpC ontext([vpc °g vp]) and a = typeOf(@retVal, [vpc °g vp])): 

(95) 

T- Value 



M; vpc \~t v : a M] \- G (Imso, vp G ,tso) : a — > r 

M; he {Imso, [vp G o G vp], return v; . . . o M is ) : void — * r 
M; h [gs \ (lms , [vp G o G vp], return v; . . . o M is )] : r 

We want to prove C\ : r: 

(96) 



T- Value 



M;vpContext(vp G ) hy v : a M; \- G (lmso,vp G ,tso) : a — > r 

ffl , — — -r n TC-ExprClo 

M ; he (Imso, vp G ,v tso) : void — > r 

T-Config 



M; h [gs \ (lms , vp Gl y_ ts )] : r 
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The type of return value v does not depend on the context, therefore it is always a. 
Realizing that (96) = (95) finishes the proof. 

OP-ReturnVoid TEq = return;. From Cq : r we know: 

(97) 



M; he (lms Q ,vpG 7 tso) : void — > r 

TC-RetVoid 



M ; he (Imso, [vpc °g vp]> return; . . . o M £s ) : void — * r 

T-CONFIG 

M; h [gs \ (lms ,[vp G o G up],returni . . . o M is )] : r 

We want to prove C\ : r (here we denote vpc = vpContext^vpc)): 

(98) 



T- Value 



M; vpc \~t ((none, _L)) VO id : v °id M\ he (Imso, vpc, tso) : void — > r 

rpaT ,, j, rrr n TC-ExprClo 

M; h c (/ms , fjPr?. ((none, _L)) vni H ts ) : void -> r 

T-Config 



M;0 h [gs | (im3n,^, ((none,l)) mM fs )] : r 
Realizing that (98) = (97) finishes the proof. 



□ 



8.4 Type soundness 

Theorem 8.23 (Type soundness for single-process programs). For any program which does 
not contain fork, send and recv constructs, if a configuration Co = [gs \ls] : r evolves to a 
terminal configuration C n , then either C n is an errorneous configuration, or C n : r. 

Proof. This is the corollary of progress and type preservation lemmata. □ 

Theorem 8.24 (Type soundness for noncommunicating part of the language). For any pro- 
gram which does not contain send and recv constructs, if a configuration Cq = [gso \ Zsn,l II 
• • • II lso, m ] '■ T evolves to a terminal configuration C n , then either C n is an errorneous config- 
uration, or C n : t x t 1 for some t' . 

Proof. This is the corollary of progress and type preservation lemmata. □ 



9 Conclusion and future work 

We have described the LanQ imperative quantum programming language. This language can 
be used for implementation of both quantum algorithms and quantum protocols. We have 
formalized its syntax, both concrete and internal, typing, operational semantics, and proved 
type soundness of the non-communicating part of the language using proofs of standard 
lemmata in style of Wright and Felleisen [WF94] and [BPP03]. 

The language can be used for proving correctness of implemented quantum algorithms. 
If a correct pairing of sending and receiving processes is assured, it is also possible to prove 
correctness of quantum protocols. 

By-reference usage of variables causes sometimes unwanted behaviour: it is possible to 
declare a program where a process sends a qubit and then it attempts to measure it. However, 
this is impossible as the qubit is then not owned by the process. Such situations are handled 
by runtime errors what also helps in debugging programs and protocols written in LanQ. 

The simulator of LanQ is also being developed and it is publicly available from address 
http : //lanq. sourcef orge .net/. 

An example of a truly random number generator and its evaluation sequence can be found 
in Appendix A. 
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A Program execution example 

The probabilistic nature of measurement of quantum particles allows us to create generator 
of truly random numbers: Let us have a quantum particle in the state = ^(|0) + |1)). 
Now we apply a measurement of this particle in the basis {|0), |1)} (so called standard basis). 
The result of the measurement is or 1 with equal probability. 

The random number generator can be implemented as shown in Figure 16. 

int mainQ { 
qbit q; 

q = new qbit(); 

return measure (StdBasis,q); 

} 



Figure 16: Program example: Random number generator 

Before the execution, we must specify the method typing context M = (-Mr, Mh, Mb). 
We have a program containing only a method main, hence the domain of the functions in M 
is {main}. M is specified as: 

Mx{main) = void — ► int 

M[{{main) = int mainQ 

Msimain) = { qbit q; q = new qbitQ; 

return measure (((none, StdBasis))MeasurementBas\s, q)] } 

The execution of the program is shown in Figure 17. For typographical reasons we have 
simplified variable properties tuple - we do not show states of f c h, f qa and ft ype as only the 
f var element of the tuple is needed in the example. 
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